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Next AUUG Meeting 


The next meeting will be on the 29th of August at Union College, University of 
Queensland, Brisbane. You should all have received notification in the mail 
by now, but if not I have reproduced the information at the end of this issue. 

While at Berkeley, Bill Joy expressed interest in coming to this meeting and I 
should know more soon. If he is coming I shall mail a note to that effect. 


In This Issue 


I know it's July. I know this issue is a month late. I think it's worth it. 

I attended the US winter meeting in Austin, Texas, and a summary of what 
happened appears in this issue. Numerous papers, glossies and other good 
stuff have also been included, making this one of the biggest issues yet. 


Change of AUUGN Editorship 


Two (sort of) applications have been received for the position of AUUGN 
editor, and money manager and chief query answerer etc etc. 

Dave Horsfall asked 'without wishing to dob myself in.....' what was involved 
and recently Bob Kummerfeid and Chris Rowles have thrown their hats into the 
ring as a team. 


AUUGN Subscription Time Again 


Volume three ends with the August-September issue. That time of year is no: 
very far off, so all you people with huge slow moving purchasing departments, 
GET MOVING! Send subscriptions to volume four to me, made payable to the 
Australian UNIX Users Group Newsletter (AUUGN). The price is still twelve 
little Australian dollars. 

When the new editor is chosen, I shall print the new address and forward any 
subscriptions on to him (her, them?). 
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My Penultimate Art Work 



Peter Ivanov 

Dept, of Computer Science 
Electrical Engineering 
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PO Box i 
Kensington 2033 
AUSTRALIA 
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Texas UNIX Users Conference 
June 23 - 26, 1981 


GENERAL CONFERENCE INFORMATION 

Message Center 


The Thompson Conference Center, 471-4652, will take messages for the 
and place them on the message board in the lobby of the LBJ Auditorium. 


participants 


Villa Capri — 476-6171. 
Hilton Inn — 451-5757. 


Shuttle Bus Information 


Shuttle buses will be provided from the Hilton Inn to the LBJ Auditorium and the 
Thompson Conference Canter. Buses will run from 8:00am-10:00am Tuesday throuqh 
Friday from 4:30pm-6:30pm iuesday through Thursday, and from 8:00arn-ll:00pm Wed¬ 
nesday through Thursday. K 

Restaurants 


A copy of the Austin Conventioneer which contains a list of local restaurants will 
be available in the lobby of the LBJ Auditorium. 

The Thompson Conference Center has a noon lunch — sandwiches, salads, etc. 

Otheilo Contest 

The Othello contest will be held in the Childress Room of the Villa Capr Confer¬ 
ence Center on Thursday from 7:00pm - 12:00 midnight. P 

Vendor Exposition 


The following vendors will be exhibiting in the McKinney Room at the Villa Capri 
Conference Center on Iuesday, 1:00pm - 5:00pm, Wednesday 9:00am - 5:00pm, and 

Thursday 9:00am - 5:00pm and 7:00pm - 10:00pm. H * 


Able Computer 
BBN Computer Corporation 
Human Computing Resources 
Interactive Systems Corporation 
Perkin Elmer and The Wollongong Group 
Santa Cruz Operation 
Whitesmiths and Western Scientific 
Zilog, Inc. 


Vendor Presentations 


The following vendors v/il 1 be making presentations in the Sherman Room of the Vi 1 - 
lO-OOpm *" 1 Conference Center- on Thursday during the Vendor Exposition, 7:00pm - 


Human Computing Resources 
Interactive Systems Corporation 
Micro Focus, Inc. 

Santa Cruz Operation 
The Wollongong Group 
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Software Tools Meeting Joe C. Thompson Center 


9:00am - 5:00pm Chairman: Allen Akin, Georgia Institute of Tech 

Open - getting acquainted. 

Allen Akin, Georgia Institute of Technology 

The Software Tools in PASCAL. 

Bill Plauger, Whitesmiths 

The Sociology and Evolution of Tool Kits. 

John Mashey, Bell Laboratories 

Coffee Break 

Data Management Tools for Large Data Sets, 

Bob Burnett, BATTELLE, Pacific Northwest Laboratory 

Writing a Compiler in RATFOR. 

Dan Forsyth, Georgia Institute of Technology 

11:30am ~ 1:00pm Lunch 

Enhancements to iS ed". 

R. R. van Tuyle, Sylvania Systems Corporation 

Adding Data Structure Support for- Ratfor. 

Wade Shaw, EXECUC0M Systems Corporation 

TOPS-20 Software Tools. 

Bruce Dawson, Digital Equipment Corporation 

Break 

Cyber Software Tools. 

Kirk Webb, The University of Texas 

Use of Software Tools in a Second Computer Science Class. 

A RATFOR Features Survey. 

Walter E. Brown, Moravian College 

Special Interest Group Meetings. 

State of the Software Tools Group Address. 


6.00pm 9.00pm Registration Villa Capri Conference Center 

Entertainment Center 

UNIX Conference Registration will be hold in the Villa Capri Entertainment 
Cenuer on the corner of East 23 1/2 Street and Swisher Street. 

A cash bar will be open during the registration. Complimentary hors d'o will 
be served. 
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June 24 


Wednesday 


9:00am - 11:30am 
9:30am - 11:30am 


Conference Registration 
What's New with UNIX? 


LBJ Auditorium Lobby 
LBJ Auditorium 


Chairman: Wally Wedel, The University of Texas 
Opening remarks. 

Wally Wedel, The University of Texas 

What's New at Western Electric? 

Bob Guffey } Western Electric 

Coffee Break (30 minutes) 

What's New at DEC? 

Joel Magid, Digital Equipment Corporation 

What's New at Perkin-Elmer? 

Roger McKee, Perkin-Elmer 

Usenix Business. 

Lou Katz, President 

/usr/group. 

Bob Marsh, President 


15 minutes 
60 minutes 

15 minutes 
15 minutes 
15 minutes 
15 minutes 


11:30am - 1:30pm 
1:30pm - 5:00pm 


Lunch 

Operating Systems and Utilities 


LBJ Auditorium 


Chairman: Mike O'Dell, Lawrence Berkeley Laboratory 


PDP-11/44: A VAX 11/780 UNIBUS Terminator. 
George Goble, Purdue University 

What is /usr/doc/services? 

Gene Dronek, Berkeley 

Four Megabytes of Memory on an 11/40. 
Clement Cole, Tektronix 


Break (30 minutes) 


Local Net and UNIX. 

Sam Leffler, Sytek, Inc. 


RT Emulation - Another Viewpoint. 

Daniel Strick, University of Pittsburg 

Bad Block Handling in 4.1 BSD. 

Bill Shannon, Digital Equipment Corporation 

Microprogramming to Improve UNIX Performance on BBN C Machine, 

Steve Emmerich, BBN Computer 30 minutes 


20 minutes 
25 minutes 
15 minutes 

30 minutes 
20 minutes 
15 minutes 
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7.00pm 10,00pm Conference Reception Thompson Conference Center 

The Conference Reception will be held at the Thompson Conference Center which is 
adjacent to the LBJ Auditorium. Wine & cheese and Beer & nachos will be served. 

June 25 Thursday 


9:00am 11:30am UNIX Languages and Applications 


LBJ Auditorium 


Chairman: Wally Wedei, The University of Texas 


Porting a Microprocessor to UNIX. 
Craig Forney, PLEXUS Computers 


10 minutes 


UNIX vs. Godzilla — UNIX in an IBM Environment. 
Tom Lyon, Amdahl Corporation 

An ARPANET-Front-end for Berkeley VAX/VM UNIX. 
Mike O'Brien, Rand Corporation 

A UNIX-based Network Operations Center. 
Brownwell Chariestrom, BBN Computer 


15 minutes 


20 minutes 


30 minutes 


Converting a Virtual RC4000 to a Virtual UNIX. 
Joshua Knight, Stanford University 

Coffee Break (30 minutes) 

Cyber C Compiler Development. 

Bill Lee, The University of Texas 


10 minutes 


30 minutes 


Basing "MAKE" ; s on Revision Levels. 
Gordon Kass, Olivetti 


15 minutes 


11:30am - 1:30pm Lunch 


1:30pm - 5:00pm UNIX Languages and Office Automation 


Chairman: Jirn Peterson, The University of Texas 

Concurrent Euclid — A Brief Outline. 10 minutes 

Chris Robertson, University of Toronto 


Compiler Construction using YACC. 

Barb Staudt, Moravian College 

PEN — The Design of a Flexible Video Editor. 
Robert Wells, BBN Computer 

Break (30 minutes) 

Office Power. 

Edward Scott, Computer Consoles, Inc. 

DEC Bus Interfacing 

Ken Omohundra, ABLE Computer 


15 minutes 
20 minutes 


30 minutes 
30 minutes 
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7.00pm "10:00pm Vendor Exposition Villa Capri Conference Center 

The Vendor Exposition will be held at the Villa Capri Conference Center in the 
MCNinney Room. Adjacent to this exposition will be vendor presentations and the 
Othello contest. 

A cash bar will be open during the Exposition. Complimentary hors d'oeurves will 
be served. 


June 26 


Friday 


9:00am - 11:30am Graphics and Data Base Systems LBJ Auditorium 

Chairman: Wally Wedel, The University of Texas 


Towards Graphics Device Independence. 

Adrian Freed, LERS. Paris 

Commercial Quality Relational DBMS for UNIX. 
Roger Sippl, Relational Data Base Systems, Inc, 

Porting Mistress to the ONYX 
John Z. Kornatowski, Rhodnius, Inc. 

Educating Users: ITS Approach. 

James Joyce, International Technical Seminars 

Coffee Break (30 minutes) 


10 minutes 
15 minutes 
10 minutes 


30 minutes 


Alpha 1: Computer Aided Geometric Design using UNIX. 20 minutes 

Spencer Thomas, University of Utah 

Leroy: Pub!ications Quality Plots 10 minutes 

Ernie Harkins, University of Colorado 


11:30am - 1:30pm 
1:30pm - 4:30pm 


Lunch 

Mi seellaneous 


LBJ Audi toriun 






Software Tools and USENIX Meetings Austin 


June 23-26, 1981 


The following is a summary of what I think was said at the 
Software Tools and USENIX meetings held at the University of 
Texas at Austin, Tuesday 23rd June through Friday 26th June 
1981. 

The summary does not purport to be true and should I have 
misquoted or drawn any wrong conclusions from anything said 
then the speakers and their institutions have my sincere 
apologies. 


Peter Ivanov 
University of N.S.W. 
Australia 
8/7/81. 
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Software Tools and USENIX Meetings Austin June 23-26, 1981 


Software Tools User Group Meeting 
Tuesday, June 23, 1981 
Introduction 

Chair: Allen Akin, Georgia Tech 


Speaker 1: 9:00am Allen Akin, Georgia Tech 

Opening Remarks - Getting acquainted 

Allen opened the meeting and welcomed all attendees® He ran through a number 
of procedural matters and details of the rest of the day's activities before 
introducing the first speaker. 


Speaker 2: 9:10am Bill Plauger, Whitesmiths 

The software tools in pascal 

ICernigan and Plauger have rewritten the software tools (book and tape) in 
pascal. xAddison Wesley are publishing it and the software will be available 
on tape or discette. 

Why did they do it? Bill quoted reasons such as greed, popular demand and as 
an exercise in portability since the pascal tools run on UNIX-Berkeley, UCSD 
and Whitesmiths' own pascal. 

Why pascal? Among other things, pascal has proved a popular teaching language 
and has better typing. Why not pascal? Problems encountered include no 
standards for separate compilation, no standards for command argument passing, 
no file naming standards and no raw I/O. Significant circumlocution was 
needed, control flow constructs necessitated the use of a lot of 'done flags' 
and data typing was too strong (fixed array sizes). 

Bill wants it to be known that the pascal version is not just 'RATFOR with 
semicolons'. A lot of work was done on extending the language without using 
any extensions, isolating idiosyncrasies outside the majority of source files 
and documentation. The new tools contain less 'sermons' or lecturing on 
style. They also do not contain crypt. 

Finally the new tools are portable but not fast, binary I/O is not fully 
supported and there is no seeking primitive. 


Speaker 3: 9:40am John Mashey, Bell Labs 

The sociology and evolution of tool kits 

John's talk might be para-phrased as 'why ugliness comes and stays forever'. 

In a fast but interesting talk he covered how programs evolve and how humans 
and organisations interact with them. Some aspects touched upon were the 
sociology of programs, programming team psychological roles and the theories 
of creeping featurism and the ecological niche. Under the heading of 
psychological roles, three types were illustrated. The 'generator' who 
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Software Tools and USENIX Meetings Austin 


June 23-26, 1981 


creates ideas and codes quickly, the "analyzer" who watches users, finds 
unspoken needs and changes to fit reality, and the "consolidator" who spends 
much of his time throwing away redundant or unused software. 

Creeping featurism would be amusing if it were not so true. One starts with a 
"thing" and adds a feature. Then someone else maybe adds a future feature 
(i.sn"t it a neat thing, and nobody need use it if they don"t want to). Then 
come needed features. When the next version is produced it must be upward 
compatible (ie. thing + release 2 of the features). Thus you finish with a 
mountain where a mole hill would have done as well. 

Programs evolve through natural selection to fill niches. They may fill a 
niche and defend it against all attack, or be so general as to fill a large 
niche, or so small (fast or specialised) as to fill a small niche well, and 
then there are ice ages, but we won"t talk about them. 

In summary, "We have met the enemy, and they is us." 


Coffee Break —•-- 


Speaker 4: 10:50am Bob Burnett, BATELLE 

Data management tools for large data sets 

Bob described a data base system, implemented in RATFCR, on a VAX running VMS 
that uses information stored with the data base files to describe to the 
various parts of the data base system the shape of the data contained in the 
data base. . 

Used mostly for statistical data bases, utilities available include a 
formatted file to DB translator, data editor/subset generator, a sort utility 
and display utility called "describe". 


Speaker 5: 11:20am Dan Forsyth, Georgia Tech 

Writing a compiler in RATFOR 

Why write a compiler in RATFOR? First Dan said, that in his view it was quite 
an accomplishment to write a compiler for a prime at all, but RATFOR was 

chosen because PL/1 was ten times slower, Pascal was flaky and assembler 

language is, well, nobody in their right minds would do that. 

Naturally what sort of compiler would you write but a C compiler. C is seen 
as a good system programming language and writing one in RATFOR would allow 
tuning of the compiler. The result is a two pass C compiler passing 

information in code tree form, producing assembler out. 

Apart from RATFOR you need lots of memory, a parser generator, a dynamic 
storage routine (common block manager) to implement heaps and pointers 

(available on the ST tape) and structures were done using a macro processor. 

——— Lunch —■—- 


AUUGN Summary Page 3 


10 


AUUGN 





Software Tools and USENIX Meetings Austin June 23-26, 1981 


Software Tools User Group Meeting 
Tuesday, June 23, 1981 

Chair: 


Speaker 6: 1:00pm R. R. Van Tuyl, Sylvania Systems Corp 

Enhancements to ed 

An editor should be. easy to use with natural intuitive commands. This speaker 
had experience with TECO, had an HP editor and got the ST editor. The STed 
was extended with the addition of a "V" command to display the line context 
(plus and minus a few lines), a 'P22' command to display the next page of text 
and limited line editing facilities. There are also commands to break and 
join lines. 

Requires terminals with back-space, speed greater than 2400 baud, an operating 
system giving good response to interactive jobs and a raw mode of input. 


Speaker 7: 1:20pm Dan Klein, Mellon Inst 

General assembler generator 

Dan described MIRAGE, the Mellon Institute Research Assembler Generator. An 
assembler is really a program that performs one to one mapping of source to 
machine code. It need not be stupid, and may even have useful error 
diagnostics. Each assembler is specified by supplying header information, 
'variables', addressing mode specifications, op codes, pseudo op codes and 
literals. 

Assemblers have been generated for 6502, 1802, 6809, DG-Eclipse, PDP11, PDP10, 
IBM360, 8080, 68000, 8048 and others. 


Speaker 8: 1:40pm Wade Shaw, EXECUC0M 

Adding data structure support for SATFOR 

PIL, a portable implementation language, is a portable language system that 
runs on several different systems. Each machine has a set of environmental 
constants used to compile correct code. 

Not a very good summary I know, but blame jet lag. 


Speaker 9: 2:00pm ’ Bruce Dawson, DEC 
TOPS-20 software tools 

Bruce gave an amusing talk on getting ST up under T0PS-20. One of the minor 
troubles encountered was insufficient storage space in the ST for file names, 
T0PS-20 uses a control-v character to flag a lower case character, and so 


Page 4 


AUUGN Summary 


AUUGN 


11 



Software Tools and USENIX Meetings Austin June 23-26, 1981 

lower case file names (eg. "abc") become ''‘va' s vb A vc". 

Redirection of standard error was a little difficult for similar reasons, but 
spawning new processes was significantly easier than some other 
implementations. The system will be available through DECUS when stable, but 
if you want it now, send a tape to Bruce at 

146 Main St., 

Mainard, 

ZK1-3/B21. 

decvax!jbd or sultan!jbd. 


- Coffee Break 


Speaker 10: 2:45pm Kirk Webb, University of Texas 

Cyber software tools 

Another implementation of ST. Kirk had to battle cyber 6bit display code, and 
got round it by implementing a 12bit extended display code. The result is 
very slow and very large but everything is there except kill, pstat, suspend 
and resume. 


Speaker.11: 2:56pm Walter E. Brown, Moravian College 

Use of ST in a second computer science class 

Moravian College has been using ST in their second computer science course 
since 1977, based on the ST book, using RATFOR as the teaching language. The 
first course serves multiple audiences and so the programming languages must 
not be esoteric (APL, COBOL, C): use a limited subset of RATFOR. 

Objectives of the second course include fostering skills at critical reading 
and analysis of programs, giving experience in programming language 
constructs, developing insight into the disciplined software development 
process, and giving experience in non-numeric programs and file processing 
tasks. Students are taught using carefully constructed examples of real 
problems which contribute to an environment conducive to good programming. 

Evaluations of the course have shown it to be popular (but only after it is 
over), difficult for faculty members to teach, and it has become almost 
central to the curriculum. Final recommendations; read the ST epilogue first, 
use supplimentary reading and use lots of anecdotes and analogies. 
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Software Tools and USENIX Meetings Austin 

Speaker 12: 3:25pm • Walter E. Brown, Moravian College 

A RATFOR features survey 

At the Delaware ST meeting a survey was conducted of possible RATFOR language 
extensions™ The survey covered 50 features which attendees were asked to rate 
A~F, where A was 'can't-do without it' and F was 'definitely NO'. Kernigan 
and Plauger were both there, and their response was that there should be less 
features. Anyway, the top five, in order of acceptance were: 

1. Macros with arguments (by a long way) 

2. Installation cook book 

3. Built in strings 

4. Conditional compilation 

5. Better diagnostics 

The least liked, most hated first, were: 

1. Ability to define symbols (eg "f' as '-*') 

2. Change '[' and ' j' to and 

3. break n 

4. do (k=l,10) body 

5* FORTRAN style comments ('c' in column one) 
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USENIX Group Meeting 
Wednesday, June 24, 1981 
What's New with UNIX 
Chair: Wally Wedel, University of Texas 


Speaker .1: 9:15am Wally Wedel, University of Texas 

Opening Remarks 

Wally ran through schedule changes and procedural matters and then gave a 
summary of the computing facilities at the University of Texas, ranging from 
Cyber-170/750s to PDPll/34s. 


Speaker 2: 9:39am Bob Guffey, Western Electric 

What's new at Western Electric 

Bob is responsible for all software licensing, of which UNIX constitutes about 
90%. At WeCo Larry Isley and Bill Murphy are the commercial contacts while 
educational queries should go to Susan Sellers (hope the spelling is correct). 
WeCo is adjusting to meet demand, and Bob expressed the hope that replies to 
queries and processing of licenses would be. very much faster. Western/Bell 
would be offering elementary support for government sites and more would be 
said about this at a later date. 


The following information was presented, valid at 1st May 1980. 

Licenses 


Software 

Commercial 

Educational 

Government 

Total 

Mini-UNIX 

6 

98 

0 

104 

V6 

89 

319 

42 

450 

PWB 

38 

43 

53 

134 

V7 

78 

176 

18 

274 

32V 

33 

74 

11 

118 

Total 

224 

710 

124 

1078 



Institutions 



Software 

Commercial 

Educational 

Government 

Total 

Mini-UNIX 

8 

265 

0 

273 

V6 

141 

775 

123 

1039 

PWB 

70 

132 

22 

262 

V7 

86 

423 

11 

531 

32V 

36 

121 

11 

531 

Total 

341 

1716 

216 

2273 

Bob also went to considerable 

effort to convey WeCo's view that software 

protection comes under' the scope of trade secret laws. 

The thrust of his 


comments was that disclosure of even one line could be viewed as a breach of 
license and that distribution to staff or students of licensable material 
should be kept to a minimum. 


AUTJGN Summary Page 7 


14 


AUUGN 









Software Tools and USENIX Meetings Austin June 23-26, 1981 

Some new packages now available are: 


Package 

Initial 

Additional 

Binary 

Educational 

UNIX/1100 

30000 

10000 

12000 

400 

UNIX/6000 

30000 

10000 

12000 

400 

C/SEL 

5000 

2500 

2500 

NA 

C/DATA 

5000 

2500 

2500 

NA 

C/80S6 

5000 

2500 

2500 

NA 


UNIX/1100 is UNIX for the UNIVAC 1100, running under EXECS. UNIX/6000 is 
really a set of utilities for use on the Honeywell 6000 to make GC0S look like 
UNIX. C for the Systems Equipment Lab 32bit machine, C for Data General 16bit 
and C for 8086 were not considered for educational release. At least I think 
that is what the 'NA' means. 

UNIVAC and Honeywell UNIX had progressed past Bell 3.0 and have been reduced 
back to level7 technology for release. Should 3.0 be licensed then more 
recent versions will be made available. 

The licensing review board currently has several packages before it. Of 
interest are a new troff (maybe August-September), UNIX 3.0 and UNIX/370. 

Some other comments: Writer's workbench is later technology and so will only 
be released should later versions of UNIX be licensed; Exchange of information 
between L6, L7, etc. licensees is under consideration; OEM fees schedules may 
be expanded; Licensees upgrading to later versions of UNIX may receive 
substantial reductions in fees. Updates for C/370 will be released, free of 
charge, to all license holders, hopefully soon. 

In all these comments Bob would not be tied down on timing. He emphasised the 
feeling that large wheels turn slowly. 


- Coffee Break 


Speaker 3: 11:08am Rich Ptak, DEC 

What's new at DEC 

Rich sketched out changes made in the DEC UNIX group. Bill Mundsen has been 
kicked upstairs and replaced by Dick Pigman. Rich and Joel Magio (or Magid?) 
are listed under UNIX system management, while UNIX engineers are Jim Barllay, 
Gerry Brenner, Fred Canter, Bill Shannon and Armando Stettner. 

The DEC UNIX tape is getting better. Send them a tape, a copy of your 77 
license and your DEC system configuration. The tape when returned should ceme 
up with minimum trouble. The address is: 

DEC 

MK1-1/D29 
Continental Blvd. 

Merrimak NH 03054 

(603) 884 4754 
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People are being trained in field service in a UNIX environment now. 


Speaker 4: 11:22am Dave Preston, Perkin-Elmer 
What"s new at Perkin-Elmer 

Apart from the terrible pronunciation of certain Australian place names, Dave 
tells us that P-E in combination with The Wollongong Group now market UNIX for 
P-E machines. P-E/TWG have more than 22 systems running used for simulation, 
CAD/CAM and software development in Canada, USA, Australia and Europe. 

He stated future P-E/TWG directions include creation and maintenance of a 
standard UNIX environment, migration of key P-E products to UNIX, enhancements 
to V7 and incorporation of other products such as networking, DBMS, compilers 
and micro-processor development systems. 


Speaker 5: 11:31am Bob Marsh, /usr/group 

/usr/group 

Bob is the president of "/usr/group", a commercially oriented user group 
formed to encourage UNIX as a defacto standard operating system and to promote 
software comparability. Incorporated in California it costs $100 per general 
member and $30 per associate. 

There are presently six subcommittees looking at licensing, standards, 
publications, programmers, vendors and end users. For further information 
contact Plexus Computers, (408) 988 1755. 


Speaker 6: 11:42am Lou Katz, Usenix 

Usenix business 

On the topic of numbers, 400-500 people attended this conference. The next 
meeting will be in Santa Monica, California, 27-29 January 1982 at the Miramar 
Sheraton Hotel, hosted by Interactive Systems. Information from the 

USENIX Association Office 
. % Box 8, 

Rockefeller Uni-versity, 

1230 New York Ave, 

NY 10021, 

(212) 360 1182. 

Usenix is now incorporated in the state of Delaware. People are needed to 
serve on various committees and also to staff tutorials planned at the Santa 
Monica meeting along the lines of ACM-SIG tutorials. 

-- LUNCH - 


AUUGN Summary Page 9 


16 


AUUGN 




Software Tools and USENIX Meetings Austin 


June 23-26, 1981 


USENIX Group Meeting 
Wednesday, June 24, 1981 
Operating Systems and Utilities 
Chair: Mike O'Dell, LBL 


Speaker 7: 1:34pm George Goble, Purdue University 

PDP-11/44: A VAX 11/780 UNIBUS Terminator 

Mike O'Dell subtitled this talk 'Super charging your VAX', George described a 
connection between a PDP-11/44 and a VAX-11/780 achieved by pulling out the 
VAX 9044 UNIBUS terminator and inserting the PDP UNIBUS, This is all very 
well, but why? 

1. Offload TTY and network I/O from the VAX 

2. Network route-through in case of a VAX failure 

3. To take care of the supposed UBA problems 

4. Use as a display system for debugging 
In practice though: 

1. Use of 4BSD has reduced the I/O problem to manageable proportions 

2. The VAX is very reliable, most failures are devices or power supplies 

3. The UBAs at Purdue work, unlike those reported at Bell and Berkeley. 

4. Proved to be useful for system monitoring as illustrated by the film 
shown during the talk. The film displayed a modified 'ps' output 
obtained by a stand-alone program running in the PDP-11/44 accessing VAX 
memory, outputting to a DMA home built terminal. The display was updated 
ten times a second. You can also use the 11/44 to display VAX memory. 

One hardware modification was needed to the PDP-11/44, a strapping to make 
addresses larger than 64KW appear as a device register. Should work for all 
PDP-lls but some (3*, 44, 60 etc) must have the CPUs running so as not to hang 
the UBA. 

If you are interested write to: 

George Goole (Software) (317) 493 9479 
Mike Marsh (Hardware) (317) 494 4226 
Electrical Engineering Department 
Purdue University, 

West Lafayette 

Indiana 47907 - . 

USA 

or on uucp 

pur-ee!ghg, ucbvax! pur-ee.! ghg, decvax! pur-ee! ghg and 
pur-ee! mike, ucb!pur-ee!ra±ke, decvaxipur-ee!mike. 
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Speaker 8: 2:00pm • Gene Dronek, Berkeley 

What is /usr/doc/services? 

This is an organisation, newly hatched, for the distribution, reprinting, 
collection, refereeing and mailing of UNIX documentation. It is interested 
particularly in articles, writeups, tutorials and even books. 

Gene and friends plan to produce a catalogue by October 1981. The address 

2490 Channing #503 
Berkeley CA 94704 

(415) 731 6154 


Speaker 9: 2:18pm Clement Cole, Tektronics 

Four megabytes of memory on an 11/40 

Clement described the use of an Abie Computer Products 'ENABLE'' device to 
attach up to four megabytes to a PDP-11/40 style processor. Some reasons why 
you would want to are: 

1. L6 was difficult to squeeze onto a 40, and L7 is worse. Schemes 
developed to solve this problem (mapped buffers and overlayed kernels) 
all result in the system getting larger at the expense of remaining user 

■ memory. 

2. PDP-11/40 type processors are prevalent and it is often difficult to 
justify the money to replace them. It is cheaper to refurbish existing 
machines. 

The system changes are on the conference tape, and a paper appears later in 
this issue of AUUGN. Finally, here are some benchmarks run on a range of 
processors: 


CPU 

Memory 

Disc 

Pveal 

User 

Sys 

11/70 

2MB 

2xRP04 

13:06 

5:02 

3:12 

11/44 

0.25MB 

RMQ2 

23:35 

7:42 

6:38 

11/34 

0.25MB 

2xRL01 

58:23 

17:12 

13:08 

11/34+ENABLE 

0.25MB 

2xRL0i 

42:19 

14:41 

10:29 


--* Coffee Break 
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Speaker 10; 3:00pm Sam Leffler, Sytek, Inc. 

LocalNet and MIX 

Sam gave a fast, thorough description of a network package available from: 

Sytek Inc. 

1153 Bordeaux Dr. 

Sunnyvale CA 94086 

(408) 734 5000 

ucbvax! menlo70! sytek! sain. 

LocalNet is designed to allow complete interconnectivity between any two nodes 
at different speeds. Supports host-host traffic at 1.5Mbits and terminal 
transmission and concentration at 120Kbits. Implemented as a number of 
modular units. The MIX host interface, a System40, connects to the MIBU8 
doing DMA transfers out to a net adapter. 


Speaker 11: 3:30pm Daniel R. Strick, University of Pittsburg 

RT emulation - another viewpoint 

"RTll is a system for people without enough money to buy a real system." With 
that quote Daniel opened his talk outlining an RT11 environment emulation 
package. The emulator lives in the top end of a 32KW address space, and the 
RT11 program survives down the bottom. Dan has implemented all bar nine of 
the RTll system requests. The emulator runs on PDPlls and VAXes and is 
available from 

Daniel Pv Strick 
833 LIS Building 
University of Pittsburg 
Pittsburg PA 15260 


Speaker 12: 3:53pm Bill Shannon, DEC 

Bad block handling in 4.1BSD 

Gone are the days when UNIX users had to pay large sums of money for perfect 
discs. The bad block handling in 4.IBSD is basad on the DEC STD 144 and works 
with RK06, RK07, M03, EM05, EM80, RP07 but not with RP06s. The support code 
is mostly in the HP and RK drivers. It makes use of the bad sector 
information stored at the end of the disc initialised by DEC standard 
formatters (EVRAC). The program BAD144 displays and maintains the table. 

Each driver's table is initialised when first entered or when the pack is 
changed (using the VolValid bit as the pack change indicator). The costs are 
a small amount more code, nothing for good block accesses and one sector table 
per drive, but the replacement sectors must be perfect. Uses the 
BadSectorError indication from the drive. 
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Speaker 13: 4:04pm • Brownell Chalstrom, BBN 

A UNIX-based network operations center 

The NOG runs on a PDP-11/70 (being ported to a C70) designed for ARPA and like 
networks (long haul packet switched net of nodes and hosts). The NOC is a 
host on ARPA, providing the following services 

@ Net status displays 

® fault isolation 

© Debugging aids for network programming 

© Network software management 

© Diagnostic and statistics collection 

© Management reports and long range planning 

© Information distribution and complaint handling 

NOC also provides information displays of node/host status, "at a glance" 
colour summaries of the network (the redder a link the higher the traffic rate 
over it) and logs tailored to suit users. In fault isolation you can prod and 
poke pieces of net hardware and software to help isolate problems. 

The future holds promise of multiple NOCs on a net, multiple nets on a NOC, 
improved reliability and expansion. 

Speaker 14: 4:35pm Walter D* Lazear, AF Data Services Center 

Air force management reporting system 

The air force data services center was faced with a management problem. On 
the large number of systems they are required support 

© Customer impressions of service are unreliable 

© No performance bench marks were available 

© No daily performance comparisons were available 

© No common reporting system was available 

© Diagnostics were too verbose or terse; needed summaries and 
consistency 

The center wide solution implemented provides 

© Standard daily reports on performance, availability, utilisation and 
workload 

© Monthly summaries ' . 

© Consistent reporting 
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The UNIX implementation involved no kernel changes, a probe program to sample 
kernel, a management summary (merging of SA and AC with some calculations) and 
a management report . giving management and high water mark reports. The 
benefits include 

© automatic tracking of failures 

© consistent analysis techniques 

© documentation of the impact of system alterations 

© reliable, sizing of kernel tables in binaries supplied to end users 
© Documentation and measurement of system size verses user community. 

Write to 


Walter D. Lazear 
Air Force Data Services Center 
The Pentagon - Room 1D983 
Washington DC 20330. 
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• USENIX Group Meeting 
Thursday, June 25, 1981 
UNIX Languages and Applications 
Chair: Wally Wedel, University of Texas 


Speaker 15: 9:08am Craig Forney, PLEXUS Computers 

Porting a microprocessor to UNIX 

This talk really described the 'design of a computer for UNIX'- Craig ran 
through design goals, standards, reliability, usability and performance of the 
Plexus P/40. Much of this information is reproduced in the company literature 
appearing later in this issue of AUUGN. 


Speaker 16: 9:22am Tom Lyon, Amdahl Corp. 

UNIX vs Godzilla - UNIX in an IBM environment 

Amdahl call their UNIX produce UTS. UTS, similar to V7, fits well into 
existing IBM environments, has been working "in house" at Amdahl for two years 
and is now available under VM/370. 

Tom described the Amdahl architecture as having 

@ Fast CPUs but with high interrupt overheads 

§ Lots of fairly cheap real memory 

@ Under VM, lots of even cheaper virtual memory 

§ Small discs, about the size of an RP06 

UNIX adaptations for the IBM environment include a 2MB in core file system 
(/tmp) and 4K blocks providing drastic decrease in I/O, decrease in interrupts 
caused by STD10 buffering and increased memory usage. 

UTS has "stupid support" for ASCII terminals caused by front end software 
simulating stupid hardware, and good support for 3270 type terminals. UTS 
interfaces 

©By batch transfers to MVS and VM 

@ Interactively allowing UTS to appear as a 3270 to MVS and VM 

© Through clean interfaces to higher level software such as PL1 
(interface generates the JCL, runs the job and returns the results), 
OSIRIS (auto logon to TSO and enter the data base system) and CRON 
which periodically submits jobs to backup MVS files and compress TSO 
data sets. 

People's perceptions of UTS are interesting. Operators tend to cause more 
harm than good as they are unfamiliar with systems such as UTS. How can a 
quiescent machine suddenly hurst into activity (CRON) at 3am? New users flock 
to UTS while old IBM users may change, but some don"t. Typical complaints 
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such as "It's a toy", "it's inefficient" or "not enough features" (like no 
VSAM) are answered by "yes it is fun, but useful", "productivity is worth 
inefficiency" and it has "not too many features". 

This was a good talk (quote on TSO, 'It may be slow, but its hard to use!') 
with amusing drawings of gorillas being harased by light planes labelled UNIX. 
The software is available, but you may have to extract it from Amdahl since 
they are not officially in the software, business. 


Speaker 17: 9:45am Joshua Knight, Stanford University 

Converting a virtual RC4000 to a virtual UNIX 

The RC4000, a 24bit Danish machine, was chosen years ago for its nice 
environment with a primary application language ALGOL68. The RC400Q was 
emulated on a PDP-11/45 computer and used primarily for data analysis. The 
11/45 was also used to control a solar observatory using MACRO under DOS via a 
PDP-11/20. 

With the previous scene set, enter a VAX-11/780 running Berkeley 4BSD. The 
task was thus to write an RC4000 • emulator and get DOS MACRO running in 
compatability mode. The conversion process was fairly straight forward and 
copy of MACRO and a minor comparability mode change to 4BSD is available on 
the conference tape. 


Speaker 18: 10:02am Steve Emmerich, BBN 

Microprogramming to improve UNIX performance on BBN C machine 

I am sure you have all heard of the BBN C machine so I do not plan to 
summarise it here. The basic thrust of Steve's talk was that the micro- 
codable nature of the C machine allows: 

a Tailoring of macro instruction set to support C operations 

6 Incorporation of system monitoring and debugging functions 

t Implementation of higher level functions in firmware with 
corresponding speed increases. 

Micro-coding certain routines has provided three fold increases in fork speed 
and block I/O is four times faster. In the future it is planned to micro-code 
getc/putc from STBIO and some floating point operations. 


Speaker 19: 10:45am Mike O'Dell, LBL 

ARPA front end for Berkeley VM UNIX 

This summary of work proceeding on an ARPA front end for Berkeley UNIX was 
presented at short notice by Mike O'Dell. Unfortunately Mike, ■speaks very 
quickly and on a topic that obviously means something to him, but I am afraid 
that as I am not an 'ARPA person' most of the collection of acronyms and buzz 
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words was flying way above my head. I do not feel I could produce a coherent 
summary of what was said. This no reflection on Mike since it was clear that 
quite a few people found what he said interesting. 


Coffee Break 


Speaker 20: 11:12am Bill Lee, University of Texas 

Cyber C compiler development 

The motivation behind putting C on a Cyber was that there was no high level 
systems language available, C is a common choice for such a language, no one 
else had done it and it seemed that it should provide a good return on the 
investment. 

Plan A was to use lex for the lexical analyzer, yacc for the parser and ccg (a 
cyber common code generator) to produce the code. It turned out to be not as 
easy as it looked, even with lex and yacc, and generating code "on the fly" 
from the parser was not the way to go. Also the ccg was written in assembler 
("some of it even had comments!") and proved very difficult to modify and 
interface to, as it was designed to run in conjunction with a cyber fortran 
compiler. > 

Plan B was similar but involved writing a new* code generator. Differences 
between PDP11 C and Cyber C are 

Item PDP11 C Cyber C 

char 8bits 15bits 

short 16bits ISbits (B register size) 

int 16bits 60bits 

long 32bits 60bits 

float 32bits 60bits 

double 64bits 60bits 

external ids 7chars, 7chars, 

upper/lower case upper case only 

character evaluation right to left left to right 

arg evaluation right to left left to right 

The runtime library is a bit big, but fast. C is a little larger than RAT?OR 
from software tools and about the same speed.. The compiler occupies (in two 
parts, cpp and cgen) 26000 words (18000 to lead) and 28000 words (24000 to 
load). To get it you need a V7 license for ycur Cyber, the Cyber loader, CMM 
(the common memory manager) and compass assembler. Selected experimental 
sites will be chosen in August 1981, with general release some time after. 
Contact 

Wally Wedel, 

University of Texas Computation Center, 

Austin TX 78752, 

(512) 471 3241. 
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Speaker 21: 11:50am Gordon Kass, Olivetti 

Basing MAKE^s on revision levels 

Gordon has made changes to MAKE to allow a better interface to SCCS maintained 
files. The new code in MAKE causes SCCS .commands to be issued to obtain a 
correct source version if one does not exist* MAKE also understands a 
revision level specifier at the front of a MAKE file to specify levels 
previous to the current, one. 

Other changes to MAKE include 

1. a ' ~z' option to give a readable trace of the operations MAKE is 
performing 

2. improved interruptability 

3. the "-n" option is transmitted to invoked MAKES correctly 

4. a '-1" option to allow include files to be combined into MAKE files 

5. fixed "$?" bugs 

6. error messages given when undefined macros are used. 

For further information contact Gordon at Olivetti Advanced Technology Center, 
10430 So. De Anza Blvd., Cuperinto CA 95014, (408) 996 3867 


Speaker 22: 12:10pm .* Bill Jolitz, Berkeley 

2BSD 

The new 2BSD distribution will be ready to ship in a few weeks. It has an E77 
that runs on I/D and non I/D PDPs. It has many similarities with 4BSD, less 
with L7. It has a fast file system, setuid shell scripts, a real-time option 
and code for file system robustness (by Tom Ferentz'^. FS robustness code adds 
11% overhead and. 250% overhead in pipe 1/0, so you may not want to use it. 
Does not have job control or vfork. Contact Bob Kridle (415) 642 6744. 


Speaker 23: 1.2:23pm ■* Walt Low, Berkeley 

F77 update 

Walt spoke about F77 for the VAX and the PDP-1I/70. The November 1980 version 
is available with fork and exec calls and no overlays. The system interface 
library is complete as is the 1/0 library and maths library. 

F77 on the VAX is very slow (about 10 lines/second) and produces slow code 
(about half the speed of VMS fortran). Additional optimisation of the first 
pass is in progress and the result should produce code that competes with VMS 
fortran. 


LUNCH - 
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U5ENIX Group Meeting 
Thursday, June 25, 1981 
UNIX languages and office automation 
Chair: Mike 0"Dell, LBL 


Speaker 24: 1:50pm Chris Robertson, University of Toronto 

Concurrent Euclid - a brief outline 

Chris, who really has nothing to do with Euclid, did a good job of remote 
presentation. Euclid is summarised in the paper appearing later in this issue 
of AUUGN. Available September 1981, the price is $500, or less if you can 
prove you are destitute. For further information contact Chris at 

Computer Systems Research Group, 

Distribution Manager, 

121 St Joseph St, 

Toronto, 

Ontario MSS 1A1, CANADA, 

(416) 978 6060. 


Speaker 25: 2:00pm Barbara Staudt, Moravian College 
Compiler construction using YACC 

Barbara wrote a parser for a subset of Rascal using YACC as a student project. 
The parser produces C code output. YACC was a pleasure to use because it 
resolved shift/reduce conflicts nicely, error recovery was relatively easy and 
tokens have values that were used to represent data types in implementing the 
parser. 


Speaker 26: 2:05pm Robert Wells, BBN 

PEN - the design of a flexible video editor 

PEN is a portable video editor that supports underlining, vertical and 
horizontal windowing and provides good error messages. It® is usable on a 
number of video terminals given terminal configuration (what character 
sequences do what) and allows keying of commands to any function key.’ PEN 
uses minimum screen manipulation and functions well, even at 1200 baud. 

The editor is object oriented, making use of lists of objects etc. Some 
objects manipulated are files (STDIO style), strings, vectors (type of 
string), nodes (generic linked lists), ilists (generic indexable lists), 
buffers and windows. 

*' V 

It runs on I/D PDPs (takes 60KB on a 70), C70, VAX and others soon. 


Coffee Break 
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Speaker 27: 2:53pm Edward Scott, Computer Consoles Inc. 

Office power 

In a talk that was fast, amusing and interesting but. not particularly 
technics*., Ed depicted office automation as expanding, helped by greater 
general acceptance of computers, rising white collar costs and inefficiency. 
The costs of technology are decreasing while the cost of people is rising. 

Using a wonderful dual projector slide system (I was sitting next to it...) we 
saxv Computer Consoles'' idea of what the ideal office might be. The executive 
enters his office, desk cluttered with the paraphernalia of business plus a 
computer terminal. Gradually you see how everything in the office, bar the 
potted plants, may be replaced by a touch of the keyboard. His diary, 
notebook, calculator, telephone book, dictionary, forms, filing cabinet and 
telephone disappear before our eyes. Slowly the office empties, leaving our 
executive, the chair, table and terminal. 1 started to reel that the 
executive looked a bit redundant, and yes, sure enough he at last winked out 
of existence. 

But, I think to myself, acknowledging that 1 do have sexist thoughts, will a 
terminal really replace the standard full bosomed secretary? 


Speaker 28: 3:33pm Ken Omohundra, ABLE Computer 

DEC UNIBUS interfacing 

Hie UNISUS is the nearest thing to a matched impedance bus, its asynchronous 
nature is nice, it's eas^ to configure and there are lots of devices made for 
it* Ken is a UNIBUS lover. But the UNIBUS has limited bandwidth due to it 
being a 16bit bus. So DSC tried to get round this by taking a PDP11/45 and 
turning it into a PDP11/7G with the 32bit wide datapath to memory. But on the 
70 NPR latency becomes a real problem in I/O bound systems. So DEG went to 
the SBI on the VAX. Is this the answer? (Ken didn't answer that.) 

Getting back to UNIBUSes, beware of salesmen who quote transfer rates or cycle 
time approaching 300-+Q0nS. Address set up time is 15QnS, slave sync is 75nS 
and address hold is 75nS totally 300nS just for bus book keeping. Your bus 
should (within reason) be configured in the order - CPU, memory, unbuffered 
DMA (like TMlls), single buffered DMA (like RKlls), silo buffered DMA (like 
EMIIs), communications DMA (DHlls etc) and finally the rest. 

When calculating bus loading eight to ten feet of bus length should be counted 
as one. bus load. Keep cables as short as possible. When the bus load count 
gets to 17 or more, think about installing a repeater. Always adjust power 
supplies when you alter the bus configuration. 

Why do some 'UNIBUS devices', particularly second source devices, sometimes 
not work on the newer machines? The PDP-11/34 was the first computer to use 
the UNIBUS as defined (in the DEC PDP11 bus handbook), eg, the PDP-11/40 did 
not drop the data lines until after master sync, and the PDP-11/34 does. 
Beware microprocessor driven devices, like disc controllers emulating DEC 
devices. They are slow, and sometimes the bits don't change quickly enough. 

Ken agreed to hold a UNIBUS 'birds of a feather' session later this evening. 
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Speaker 29: 4:00pm John Mashey, Bell Labs. 

Small is beautiful and other thoughts on programming strategies 

The first slide labelled what followed as the fifth iteration of a popular 
talk John has given from time to time. John had lots of slides, talked very 
fast and about the only documentation I got was a list of references and a few 
quotes. The references appear later in this issue and some of the quotes 
below are attributable to the people in that list. I have no idea which ones. 

There seem to be three approaches to a programming problem 

© Do it right. Spend a long time planning, design well and implement 
the right thing first go. 

© Do it over. Do it, and so learn what you really want to do, and then 
do it right the second time after the massive first version has 
failed massively. 

© Do it small and do it with tools. Pick appropriate timing, emphasis 
and risk. Focus preplanning. Build something fast and be prepared 
to fail quickly. 

And now to some quotes.... 

Failure is the norm. 

Don''t look back, something may be gaining on you. 

Adding manpower to a late project only makes it later. 

Long project + staff turnover ~ steady state zombie 
Things don"t get smaller, they get bigger. 

Things don't go from bad to good, they go 

from better to ok, 
from ok to worse and 
from, worse to abysmal. 

The black hole principle: The more you put in, the less you get out. 
All features have users; Bugs <==> features. 

Premature optimism is the root of all evil (Knuth). 

We have met the enemy and they is us. 
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USENIX Group Meeting 
Friday, June 26, 1981 
Graphics and Data Base Systems 
Ghair; Wally Wedel, University of Texas 


Speaker 30: 9:09am Adrian Freed, LERS 

Towards Graphics Device Independence 

Adrian described a library of C functions that implement primitive object 
drawing, character sets, windowing, scaling and scan conversion. Algorithms 
for raster and vector devices are included and the library has been used to 
implement one interface for three quite different devices. 

The algorithms provide 

General: Scaling and translation (windowing), and clipping. 

Raster Scan: Line, circle, arc, character sets and raster scan converter. 

Caligraphic: Line, circle, arc and character sets. 

A problem with the package is that it uses only 16bit arithmetic. 


Speaker 31: 9:25am Roger Sippl, Relational Data Base Systems, Inc. 

Commercial quality relational DBMS for UNIX 

Roger described the MARATHON system which features the INFORMER query 
language, ENTER I data entry program, application language library, full data 
integrity for multiple users, audit trail backup and recovery and report 
writers. 

There is a glossy later in this issue. 


Speaker 32: 9:45am John Z. Kornatowski, Rhodnius Inc 

Porting Mistress to the ONYX 

I have published Mistress glossies in earlier issues. The porting effort 
encountered logistic problems (45%), problems with ONYX C (45%) and other 
( 10 %). 

Logistics problems manifested as a lack of ONYX systems in Canada, slow 
delivery, limited availability of machines when they were delivered, no C 
compiler ordered with the machine, no documentation when C did arrive and no 
high speed I/O device on . the ONYX (source transfered by serial line, 6hrs/MB). 

The C problems started with a compiler labeled "pre-release, use at your own 
risk". There were three versions of C delivered called CC_ PCC and ZCC none 
of which was well documented. They produced different (some incorrect) code 
and implemented different dialects of C. John finally used all three Cs. 
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There were some Mistress source problems such as ints declared as chars and 
some other C compiler dependencies, but it all works now. The Mistress ONYX 
and PDF code is now the same. To get Mistress write to John at 

Rhodnius Inc, 

Product Information, 

PO Box 1, Station D, 

Scarborough, 

Ontario MIR 4Y7, Canada, 

(412) 922 1743. 


Speaker 33? 10:07am James Joyce, International Technical Seminars 

Educating users: ITS approach 

Jim demonstrated the "tinker-toy" teaching method he employees. Probably It 
would lose in the translation if I described this portion of the talk. Other 
educational hints are 

® Visuals should be that; the less text the better and if text is 
there break it up. 

® Exercise is the key to success. You. can"t give enough examples and 
hands on teaching. 

§ Team teaching is useful. It is often useful to have a paid stooge in 
the audience to prompt with questions and act. dumb. 


Coffee Break —-- 


Speaker 34: 11:08am Spencer Thomas, University of Utah 

Alpha 1: Computer aided geometric design using UNIX 

Alpha-1 creates object representations using D-spline surfaces (a new way of 
looking R-spline surfaces), Baumgart (spelling?) topology description, data 
types and generators. Graphics facilities provided or planned include line 
drawing displays for interactive design, raster displays for high quality 
shaded images and numeric control of machinery. Pretty pictures. 

Why UNIX? Already had it, already had C, homogeneous I/O, the shell is a good 
command language, MAKE, easy process control, changes relatively easy to make 
and other miscellaneous niceties. 
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Speaker 35: 11:32am - Ernie. Harkins, University of Colorado 

Leroy: Publications..-.quality plots , 

Ernie is from the Cooperating Institute for Research in Physical Sciences 
(CIR.ES) computing facility and is into "making pretty pictures". Leroy is 
written using YACC, has lots of fonts and is on the conference tape. The. 
pictures were nice. 

When he explained that a Tektronics 4012 lost information at high speed 
someone offered the information that filler characters could be used to get 
round the problem. Quote, "Filler characters? What a nauseating idea!" 


Speaker 36: 11:50am Wally Wedel. University of Texas 

Close 

Wally thanked all the people who helped out with the conference, the speakers 
and USENIX board. There were twelve tapes submitted and he hopes that a 
consolidation of the contents will be distributed within three months. 


Page 24 • AUTJGN Summary 


AUUGN 


31 





Modifications to XINECf to Allow Four Mega Bytes of Main 
Memory on a 1 i /40 Class Processor 

Clement 7 . Cole 

Computer Research Group 
Computer Research Laboratory 
Tektronix Laboratories 


Sterling J. Baxley 

Computer Resource Department 
Technology Group 


ABSTRACT 

This paper describes the modifications to UNIX Version 
7, to efficiently use the 4 Megabyte extented addressing 
capabilities of a 11/40 class processor after hardware 
modification. Discussed are the reasons why such 
changes are desirable, what parts of the machine are 
effected and a few comparisons of the results. 


June 20, 19E1 


f UNIX is a Trademark of Bell Laboratories. 
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Modifications to UNXKt to Allow Four Mega Bytes of Main 
Memory-on a 11/40 Class Processor- 

Clement T. Cole 

Computer Research Group 
Computer Research Laboratory 
Tektronix Laboratories 

Sterling J. Huxley 

Computer Resource Department 
Technology Group 


Introduction 

We will be describing the changes that were made to a 
standard UNIX system to allow the addition of extra main memory 
beyond that DEC normally allows. We will first be discussing the 
reasons for such radical departure from a normal system. Next we 
will discuss the changes made, and the effects that these non¬ 
standard hardware and software changes have to a user program. 
Last of all we will lock at some performance statistics and see how 
they relate to the earlier justification for this work being started. 


In 1972, Ritchie and Thompson released to the world the Fifth 
Edition of the UNIX Timesharing System[l'j. This system was 
designed to run with minimal hardware. In 1878, the Seventh 
Edition of UNIX was released with the caveat that it must run on 
larger PDF/11 systems. The term "larger' 1 was intended to mean 
DEC PDF U's with a hardware kludge to allow a seventeenth 
address bit. 7his kludge is known as the separate instruction and 
data bit 1 . This bit separates instruction and data fetchs to main 
memory on the Unibus[2]. The term "minimal" included the 11/40 
and 11/35 processors that do not support the separate I/D 
feature. In chose 6 years and two releases of UNIX what happened? 

For a first order view, UNIX was improved, at the expense of 
size. These improvements were assorted, from simple bug fixes, to 
modernize an original design decision that became inappropriate. 
The fundamental change was to correct for a hardware problem 


| UMTXir a Trademark of 'Bell Laboratories. 
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that became acute over those same 8 years: disk technology 
improved drastically, forcing the earlier file block to physical disk 
block mapping to be unusable. 

The Seeking Problem 

When UNIX Version 6 was released, UNIX was forced into viewing 
each large, DEC RP03 style, disk as many smaller pseudo disks. 
This feature was introduced because the fundamental data size on 
a PDF 11 is a 16 bit integer. An RP03 has . more than 65536 
physical blocks per disk. Later DEC introduced the RP06 disks 
"that contains about 150 Megabyte of storage. Technology was 
bound to improve again, making the pseudo disk solution a little 
unbearable. Clearly, there are times when a user would wish to 
address every physical block on the disk. 

Generic UNIX does supports a system call to allow a user 
program, to address any byte in a file. The seek system call takes 
three parameters[3]. The descriptor of the file to seek on, the 
amount to seek, and a third parameter that specifies the type of 
seek, i.e. seek relative from the beginning, end or current file 
position. The UNIX operating system supports a data abstraction 
that allows a user program to view any device as a sequential file 
of bytes. Using the seek system call and this data abstraction, we 
can write programs to manipulate any byte on any disk 15 . 
Unfortunately, as we discussed, before, the operating system had 
difficulty building the complete abstraction for large disks. These 
principles beget Version 7's new seek system call. 

In Version 7, the seek system call was removed and replaced 
with a Iseek (long seek) system call[4]. The difference between the 
two calls is that the parameter that specifies a seek count, was 
changed from a short integer (16 bits), to a long integer (32 bits). 

The change from a short to a long had major ramifications. 
Not only did it nearly double the size of many of the already large 
tables that the operating system needed to keep in main memory, 
but in the operating system size was increased in tiny increments 
by arithmetics. What used to be a add instruction, now needs to 
be an inline expansion for 32 bit arithmetic. Not that these 
changes are terrible, but many of these expansions have the 
tendency to slowly add to the size of the kernel. See the appendix 

2] A block is the fundamental unit of storage on a disk drive. It contains 512 
bytes of 8 bits each. 

3] An example of a program that would like to manipulate an entire disk at a 
time is a program that operates on entire file systems, like dump(lm), 
restor(lm), and icheck(lm). 
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for a demonstration of the code expansion problem. 


Solutions to Address Space limitations 

The Version 7 UNIX Kernel (adding both instruction and data) 
■would not fit into the 64k byte limit that a PDF 11/40 class 
processor imposes, and still be able to have a several runabie 
processes in the kernel process tables. To be truthful, large UNIX 
Version 6 systems had much difficulty fitting into the 11/40's 
address constraints. Man}' different groups created ingenious 
schemes to win back kernel space. The most notable were the 
Calgary Buffer Modifications that moved the system I/O buffers out 
of the normal kernel address space and made the system change 
its memory management registers to address the data in those 
buffers. For small 11/40 installations these modifications were 
not completely necessary. However, if these modifications were 
not installed, UNIX would have to be “shoe horned” into fitting the 
address space available from the DEC 16 bit virtual addresses. 
When Version 7 came, these modifications became necessary for 
even the smallest ll 3 s to be able to run more than five or six 
processes (not users) at the same time. Soon, another interesting 
method "was suggested by people at UC Berkeley[5]. They suggest 
that the kernel be “overlayed.” This overlay scheme is not a 
classical disk overlay, but for efficiency, an in memory overlay. 
Meaning that the whole kernel would be kept in main memory at 
one time, and the memory management registers changed as 
needed. 


The “in-memory’ 1 overlay method, when it is used with the 
Calgary buffer modifications, seems to be among the best methods 
of gaining back kernel address space to date. Unfortunately, 
these modifications have one unhappy side effect. They trade off 
kernel size at the expense of available user memory. A PDF-11/40 
class processor’s memory management unit can only address 18 
bits (256 K bytes) of main memory. It is easy for a UNIX kernel to 
become greater than 1/2 of that size and in some cases be closer 
to 3/4’s of our 256 K byte limit. Remember that the reason for 
letting the size of the kernel become large in the first place was to 
allow more that a few processes to try to run at- the same time. We 
now have enough kernel buffers, but not enough main memory; 
and unhappy Catch 22. To this end, the software people asked the 
hardware people for a little help. 


Able Computer Corp. produced exactly what was needed. They 
have a new memory management board called: ENABLE. Ibis 
board works in conjunction with the DEC memory management 
unit to produce 22* bit’s worth of address on a machine that 
previously had 18 bit’s worth. Making the theoretical size, of the 
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address space of this new hybrid 11/40 class processor 4 , 4 mega¬ 
bytes. 

The ENABLE board plugs into a new backplane and .creates a 
new 22 bit Modified Unibus[6]. It works- without other 
modifications to the hardware. 

With the use of this new hardware UNIX now can address the 22 
bit’s of address space needed. By overlaying the UNIX kernel, and 
for that matter, any user program, it is capable of growing 
extremely large. The changes to the UNIX kernel to support the 
ENABLE board have no affect on user programs. 



When a program runs on a unmapped PDP-11, the processor 
will produce a 18 bit address. With mapping turned on, this IS bit 
address is referred to as a virtual address. To produce a 22 bit 
physical address there are two relocations that a virtual address 
must go through. The DEC relocation hardware will produce an 18 
bit address. The ENABLE relocation will transform the DEC 18 bit 
address into a 22 bit physical address. 

1. BEG relocation 

A 18 bit DEC virtual address (VA), produced by the PDP 11 cpu, 
builds a 18 bit DEC physical address (PA) as follows: 

DEC VA bits 13-15 (three bits) are used to index one of 8 DEC 
Page Address Registers or PAR’S. The lower 12 bits of the 
indexed DEC PAR are added to the DEC VA bits 6-12 (seven 
bits) to produce a 12 bit field which goes into bits 8-1? of the 
DEC PA.* Bits 0-5 of the DEC VA are concatenated with the 
result to produce DEC PA bits 0-5. 

The 18 bit DEC PA is now gated to a normal 18 bit Unibus. 

2. ENABLE Relocation 

The ENABLE relocation process is analogous^ to the DEC 
relocation. 

The ENABLE PAR'S are indexed by bits 13-17 of the DEC PA 5 . 

4:] The name of the macro that we have used in code found in the appendix 
for this new hybrid is FQRTYZ. We will have the standalone system set the 
global variable “cputype” to 1 greater than the normal, e.g. 4.1 for an 
11/40 class processor and 48 for an 11, 45 class processor. 

5) 5 index bits means that 32 PAR'S can be accessed but only 16 can be used 
for an 11/40 installation. The other 16 PARs can be used by an 11/4-5 
class processor. For the 11/40 we are using 8 for kernel and 8 for user 
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The contents of the indexed ENABLE PAR are added to hits 8- 
12 of the DEC PA to yield a 16 bit field which is placed in bits 
6-21 of the ENABLE PA. Bits 0-5 of the DEC PA are again 
concatenated with the result to produce ENABLE PA bits 0-5. 
Note that is means that the original DEC VA Bits 0-5 are passed 
unchanged to ENABLE PA bits 0-5. 

This 22 bit address is now gated on to a special 22 bit 
MODIFIED Unibus. This new Modified Unibus, is electrically the 
same as the one found in an 11/44. 

Setting up the Two Memory Management Units. 

In order to achieve 22 bit relocation, the DEC Memory 
Management Unit must be effectively NOP-ed. This is done by 
placing data into the DEC PARs so that when the DEC 18 bit 
translation is operating, the 18 bit result will index into the 
ENABLE PARs without adding any other relocation. Because we 
know that the ENABLE board uses the upper d bits of the DEC 18 
bit PA as an index, we should only set these bits in the DEC PARs. 
Contained inside a short routine in mch4G.s, we will once and only 
once, set the contents of the DEC PARs. After that time, our new 
UNIX will use the ENABLE PAR’S like the older versions had used the 
DEC PAR'S. 

3. Setting up DEC Page Address Registers 

The DEC Kernel PAR’S (DKP) should be initialized as follows: 

DKPO = 0000 
DKP1 = 0200 
DKP2 = 0400 
DKP3 = 0800 
DKP4 = 1000 
DKP5 = 1200 
DKP 6 = 1400 
DKP? = 7600 

Notice that the lower 7 bits of each number are 0. Bits 7-10 of 
the DEC PAR is used as an index into the ENAJ3LE PAR’S. 

To explain why 7600 is placed into DKP7, we must remember 
that there exists a short period of time when DEC memory 
management is turned on and ENABLE memory management turn 
off. During this window, there are references made to the I/O page 
when we activate the ENABLE Board. Meaning, the DiiiC memory 

operations. For an 11/4-5, ?/e would have 8 for kernel I space, 8 for kernel 
D space, 8 for user I space and 8 for kernel D space. 
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management must be set up to handle references to the I/O page 
with and without the ENABLE board active. DKP7 being 7800 
means that when ENABLE memory management is' on all 
references to the I/O page go through ENABLE PAR 31 (DKP7 bits 
7-11 = 31). The DEC kernel PAR’S index into ENABLE PAR’S 0-8 and 
31. Note therefore that we are using 7 ENABLE PAR’S and then 
skipping the next 24 ENABLE PAR'S. 

DEC user PAR’S are initialized with 2000 and increment by 200. 
Therefore, DEC user PAR’S index into ENABLE PAR’S 8-15. 

DUP0 = 2000 
DUP1 = 2200 
DUP2 = 2400 
DBP3 = 2600 
DUP4 = 3000 
DUP5 = 3200 
DUP6 = 3400 
BUP7 = 3600 

Once the^ DEC PAR’S are initialized it is not necessary to 
change them 6 . Thereafter when switching user processes only the 
ENABLE USER PAR7" will be modified. Also, A version of UNIX can he 
used that allows more than 84k bytes of main store to be used,by 
a program while only manipulating the ENABLE Kernel PAR’S. 

A Minor Mishap with I/O Mapping 

The Unibus was designed to support 18 bit DMA I/O devices[2]. 
Therefore on the 22 bit PDP-li’s (11/7.0 class), an I/O map, called 
Unibus Map, must also be provided to translate from 18 bit 
addresses produced by the DMA hardware to the 22 bit addresses 
that the memory system sees. It should be noted, that all DMA 
hardware accesses memory at different times and through 
different drivers than the cpu uses for an instruction or data 
fetch. Which means on an 11/40 and 11/45 class processor, the 
I/O subsystem runs unmapped, producing physical address in 
main memory. Able exploits the fact that both the 11/45 and 11/ 
40 class processors do not need a Unibus Map, Fortunately, DEC 
did not assign any other I/O devices residing at the I/O map’s 
location for these processors. Allowing our version of UNIX to 
initialize this map, on our modified machines, in the same manner 

6] The only time the kerne] must modify these while running normally, is 
when you wish io support the fuiword subroutines used by the 
unsupported phyio(2) system call. This is because this subroutine is using 
the mfpi instruction, which makes some rash assumptions about the state 
of the DEC memory management registers. 
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as unmodified UNIX does on the 11 /70 class machines. 

Unfortunately, it was found that the ENABLE board cannot be 
running in 22 bit relocation mode with I/O mapping turned off. 
Before enabling the ENABLE board both the I/O mapping and 22 
bit relocation bits in the ENABLE S3R3 must have been set. 


UNIX would like to set up the I/O mapping registers after-the 
kernel is loaded and running in 22 bit mode, bince both I/O 
mapping and 22 bit relocation bits must be set at the same time 
the I/O map is enabled before the map is initialized! UNIX is now 
running with an undefined I/O map. 


These two bits should be independent of each other. The 
system could then boot and run in 22 bit mode with 3he. ±/ 0 map 
turned off. The initialization code for the I/O map could be left in 
machdep.c instead of having to move it into the assembler assist 
that sets up the memory management unit. 


Some Results 

The authors ran a simple bench mark on four UNIX 
configurations. These are: an unload 11/70 with 2 megabytes of 
main memory and 2 RP06s; an unload 11/44 with 1/4 megabytes 
of main memory and 1 RMQ2; an 11/34 with 1/4 megabytes of 
main memory and 2 RLGls; and the same 11/34 with 1/a 
megabytes of main memory and the new ENABLE unit installed. We 
understand that you must mellow these statistics due to the fact 
that were running a UCB kernel on the 11/70 and 11/44. We were 
running a DEC kernel on the 11/34 7 . The actual bench mark was 
to recompile the entire UNIX kernel from zero. What was typed into 
UNIX: 

& rm dev/No sys/*.o 
S time sh -x makeit 

The file “makeit” contained the lines: 


7] The plan was to show you the differences after we had brought up the UCB 
overlay kernel on the 34. Unfortunately, we were using borrowed memory 
from Mostek Corporation for the extra 1/4 mega on the 34. We had to give 
the memory back before we received the overlay code from ULB for the 
11/34. We also were using a borrowed 11/34 from Tektronix Computer 
Automation Support. We had to give this machine back after one week. 
Once we get some system time again we will running the correct bench 
mark, and republish these results. 
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cd dev 
make 
cd ../sys 
make 
cd ../conf 
make unix 


Some Numbers 


CPU Tvr>e_ 

Real. . _ 

__Us_er 

System] 

11/70 

13:06.0 

5:02.9 

3:12.3 J 

11/44 

23:35:0 " 

7:42:0 

6:38:7 j 

11/34 

58:23:1 

17:12:3 

13:06:2 

11/34 with ENABLE 

42:19:2 

14:41:8 

10:29:21 


The 11/34 should come closer to the 11/44 performance once the 
UCB changes have been added. Note that the extra memory help 
the 11/34 because it did not have to swap to the extremely slow 
ELQls. When the Calgary mods are added the RL's will look much 
better, because this kernel will be allowed to have 50 or 60 buffers. 

For a matter of reference, we used the DEC Y7 kernel for the 
base 11/34 installation. This was because we felt that the people 
at DEC would have a better idea of how to tune the an unmodified 
34 system than we might. It also gave us a reference base. To 
obtain their code write to: 

The DEC UNDC Group 
DEC, Continental Blvd 
MK1-1/D29 
Merrimack, NH 03054 

I believe there is a charge for this tape, but check with DEC first. 

In the case of the 11/44 and 11/70 we are running a Modified 
UCB Kernel, from the San Fransico,-prelease 2BSD system. We 
have added a new TTY driver. Hopefully this will come in sync with 
the UCB one. To obtain this tape, write to: 

Bob Kridle 
EECS Dept. 

Cory Hall 
UC Berkeley 
Berkeley, CA 94720 
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Appendix A 

Demonstration of Code Expansion - code.c 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 


/* 

* a demonstration of the add problem 

*/ 

short glob-short; /* This is short in global space V 

short short_glob; /* This is short in global space */ 

long glob—long; /* This is long in global space */ 

long long—glob; /* This is long in global space */ 

main () 

i 

short local—short; /* This is short in local space */ 

short short—local; /* This is short in local space */ 

long local-long; /* This is long in local space V 

long long—local; /* This is long in local space */ 

glob—short = 0; 

short—glob = glob—short + 10; 

local—short = 0; 

short—local = local—short + 10; 

glob—long = 0; 

long—glob - glob—long 4 10L; 
local—long = 0; 

long—local - local—long + 10L; 

i 
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Appendix B 

Demonstration of Code Expansion - eode.s 
.data 


.comm 

—glob—sh,2. 


.comm 

—short—g, 2. 


.comm 

—glob—lo,4. 


.comm 

.text 

—long—gl,4. 


.globi 

—main 


jsr 

r5,csv 


sub 

Sl2.,sp 


clr 

—glob—sh 

/ line 20, file "code.c" 

mov 

—glob—sh,rO 

/ line 21, file "code.c" 

add 

$IO.,rG 


mov 

rO, .short—g 


cir 

-8.(r5) 

/ line 23, file "code.c" 

mov 

-*8.(r5),r9 

/ line 24, file "code.c" 

add 

8l0.,r0 


mov 

r0,-10.(r5) 


clr 

—glob_lo 

/ line 26, file "code.c" 

clr 

—glob—lo'+2. 


mov 

—glob—Io+2.,rl/ line 27, file "code.c" 

mov 

—glob—lo.rO 


add 

810.,rl 


adc 

rO 


mov 

rO,—long—gl 


mov 

rl f —long—gl+2. 

cir 

-14. (r 5) 

/ line 29, file "code.c" 

clr 

-12.(r5) 


mov 

-12,(r5),rl 

/ line 30, file "code.c" 

mov 

-14.(r5),r0 


add 

810.,rl 


adc 

rO 


mov 

r0,-l8.(r5) 


mov 

rl,-l6.(r5) 


jmp 

cret 
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Appendix C 

Virtual to Physical Address Mapping 
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CONCURRENT EUCLID; COMPARISON 
WITH C AND PASCAL. 


J.R. Cordy, R.C. Holt 
B. Spinney, C. Levels 
Computer Systems Research Group 
University of Toronto 
Toronto, Ontario, Canada 


ABSTRACT 

It is generally recognized that it is desirable 
to do system programming in a high-level languaqe. 

The C language, coming out of the UNIX (Western Elec¬ 
tric trademark.) operating system is attrative because 
it yields efficient machine code. The Pascal language 
is attractive .because it provides relatively elegant 
structuring combined with strong type checking. By 
comparison with these two languages, Concurrent Euclid 
offers their combined advantages, including both ef¬ 
ficient code and strong typing. In addition,it pro¬ 
vides controlled access to machine-dependent features, 
separate compilation and language-specified concur¬ 
rency. Portable Concurrent Euclid compilers are under 
construction with replaceable code generators for 
various computers including PDP-11, VAX, MC68000 and 
MC6809. 


INTRODUCTION 

Concurrent Euclid was designed with 
these goals: convenient features for devel¬ 
oping compiler/systerns software, small fast 
compiler, portable selfcompiling compiler, 
and high-quality cede. 


Concurrent Euclid thus has qoals simi¬ 
lar to those of the C. Languaqe. It diverges 
from C primarily in enforcing a programming 
discipline that improves reliability and de¬ 
creases maintenance costs. For example, 
strict visibility rules minimize interaction 
among modules. Generally, code generated 
by the Concurrent Euclid compiler is at 
least as good as that of C, and considerably 
better for procedure calling. 


Concurrent Euclid is a direct descen¬ 
dant of the structured language Pascal. 
Concurrent Euclid has been made cleaner than 
Pascal by clarifying type compatibility, 
.eliminating aliasing and function side ef¬ 
fects, providing user-controlled visibility, 
etc. Also provided are language features 
‘needed for systems programming, such as 
; absolute address variables, type converters, 
;separate compilation, and concurrent proces¬ 
ses. Like some implementations of Pascal, 

!optional runtime code checks subscripts and 
lease selectors, and maintains the source 
:line number in a register. The result is 
■’that it is seldom necessary to take a dump 
: to do debugging. 


! Pluggable coda generators already exist 

’ fob Concur tent Due 1 id Cor the MCfddOOO, 
iMC6809,.and the PDP-11. These generators 


are attached to a machine independent com¬ 
piler front end (Spinney). 


EVOLUTION OF CONCURRENT EUCLID 

The Eucxid programming language is a 
modification of Pascal,designed for writing 
systems programs that can be verified using 
state-of-the-art techniques. The important 
features added to Pascal include: explicit 
control of visibility of names, e.g., ex¬ 
plicit importing and exporting of identifi¬ 
ers from modules; Partitioning pointers into 
distinct c.oilections: extending types to 
have parameters so that a tvpe declaration 
can be a template for many different inst¬ 
ance types: module types to provide data 
abstraction and information hiding; general¬ 
ization of Pascal constants to allow their 
values to be calculated at run-time: machine 
-dependent features f or immediate access to 
the underlying hardware; and assert state¬ 
ments , 

The Euclid languaqe is described in 
the Euclid Report (Lampson). The language 
design was commissioned by the Defense 
Advanced Research Project". Agency of the 
U.3. Department of Defense in IS75. 

The language was to be based on Pascal 
arid designed to facilitate verification of 
programs using formal proof techniques. 

j An early attempt at implementation of 
Euclid was undertaken at the Bystems 
Development Corporation early in 1.977 but 
was never completed. : 
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The first successful implementation of 
Euclid, called Toronto Euclid, was carried 
out as a joint effort of the Computer Systems 
Research Group at the University of Toronto 
and the Special Systems Division 
of I.P. Sharp Associates Ltd. (Wortman). 

A prototype of a UNIX-compatible oper¬ 
ating system (called TUNIS) was implemented 
in Toronto Euclid. Based on this experience 
with the Euclid language, the language 
Concurrent Euclid was designed. Concurrent 
Euclid omits difficult to compile features, 
notably parameterized types , and adds feat¬ 
ures needed for systems programming, notably 
concurrent processes. Concurrent Euclid is 
"nearly" a compatible subset of Euclid. It 
is self-compiling and was originally com¬ 
piled by the Toronto Euclid compiler. The 
Toronto - Concurrent Euclid compiler is fast 
(it compiles a pass of itself in about 10 min¬ 
utes) compared to the Toronto Euclid compiler. 
A new version of TUNIS is presently being 
developed in Concurrent Euclid. 

COMPARISON WITH C 

The C language has been highly success¬ 
ful as a production systems implementation 
language. It is notable for providing good 
quality machine code. Most software in 
UNIX systems is written in C. C 'and Con¬ 
current Euclid have similar goals in that 
both are intended to support systems pro¬ 
gramming. Both have portable compilers, 
allowing them to be used for a variety of 
machines. The most striking differences 
between the two are (1) C dr a much more 
primitive, Fortran-like language and (2) C's 
data structuring is low-level and insecure. 
Where,..Concurrent Euclid has strongly typed 
records and pointers partitioned into col¬ 
lections, C provides "structures" without 
restrictions or use of the dot operators 
and pointers that are treated implicitly 
as integers. Where Concurrent Euclid op¬ 
tionally checks subscript bounds, C has no 
linguistic notion of a subscript being 
bounded (I). 

Where Concurrent Euclid provides 
"modules for data encapsulation, C supports 
globally accessible "external" data in a 
way analogous to features of PL/I or Fortran. 


These differences lead inevitably to 
' much easier testing and less costly main¬ 
tenance in Concurrent Euclid, because sc 
many programming errors are caught at com-. 

• pile time or in irdtial testing. By way of 
i comparison, in Concurrent Euclid, a wild 
' subscript is immediately isolated, while 
: in C, this situation leads to remote data 
■ or program corruption and laborious in- 
1 spection of core dumps. j 

, The following example from a C program 

illustrates the lack of checking implied by 
■' C‘s low-level features. 
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C Statement Purpose Result 

1 —-1: Set j to-1 Set j to i-1 

i£(j»i) If j equals i Set j to ir 

see if j is 0 

{printf (i) ; Print j Print garbage 

or crash 

skipline;} Skip a line Do nothing 

Each line seems reasonable and might be ex¬ 
pected to achieve its purpose. Each could 
easily be produced through oversight, ignor¬ 
ance or clerical error. Each is legal in C. 
The unfortunate results come about because 
(1) the operator =- is ambiguous, (2) equal¬ 
ity is written as == but = is a leqal infix 
assignment operator, (3) the type and num¬ 
ber of procedure parameters is not checked 
and (4) a' procedure name, skioline in this 
case, without following parentheses is a 
value equal the procedure's address. 

This example does not illustrate the 
most common and insidious kind of C buq, 
namely, pointers gone wild in innocent 
looking expressions. By comparison, disast¬ 
ers such as these are cauqht at compile-time 
in a Concurrent Euclid program. 

One mierht auess that since C is a 
lower level language than Concurrent Euclid, 
code for C programs would be more efficient. 
In fact, algorithms compiled by the Concur¬ 
rent Euclid compiler are tvbicallv about 
10% smaller and faster than the same algor¬ 
ithms in C. .For this comparison;- we have 
assumed that Concurrent Euclid omits (I) 
subscript checks and (2) code to put the 
li ne number in a register. These two op¬ 
tions each cost about 15% in time and soace 
when used and are unfortunately not avail¬ 
able to the C programmer. We have assumed 
that C's optional optimizer pass has been 
run. (Concurrent Euclid has no such pass). 

Our comparisons have been for PDP-11 machine 
code. 

Concurrent Euclid's superior efficiency 
derives primarily from the excellent code it 
produces for procedure calling. For example, 
the "do nothing" procedure executes only one 
instruction in Concurrent Euclid, but about 
16 instructions in C. In standard tests of 
procedure efficiency such as (Wichman), 
Concurrent Euclid typically beats C by from 
:50% to several hundred per cent. Since 
systems programs usually consist 'of larqe 
numbers of small procedures, this efficiency 
pays off. 

To summarize our comparison of C and 
Concurrent Euclid, C is a lower-level, less 
secure language and Concurrent Euclid pro¬ 
vides more efficient code. 

, COMPARISON WITH PASCAL 

The Pascal, language has proven extreme¬ 
ly succossfui. It in widely used, osuecini- 
ly on microprocessors, and has influenced 
’many systems programming languages. It en¬ 
courages structured, reliable programming 
..via its relatively v/ell designed data types 
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and control constructs. 

Pascal does not provides various feat¬ 
ures needed for systems programming, such as 
separate compilation, variables at absolute 
addresses and concurrent processes. These 
features are available in Concurrent Euclid. 

; Most existing Pascal compilers do not. 
produce code that is as efficient as that 
of C, This lack of efficiency has prevented 
Pascal from being used in many time or space 
critical applications. Concurrent Euclid 
provides the elegance and reliability ; of 
Pascal without sacrificing either efficiency 
or features needed for systems programming. 

Ten years ago Pascal was a considerable 
step forward in language design. However, 
it contains various trouble spots and omis¬ 
sions that are corrected in Concurrent Euclid 
We will give two examples. 

Most importantly, Euclid provides data 
encapsulation which is missing in Pascal. 

In the following simple example the abstract 
object Stack has its implementation hidden 
from its users. Outside the module, only 
the entries Push, Pop and Value can be ac¬ 
cessed. A module such as Stack can foe tuned, 
modified and maintained without fear that 
another program depends on Stack's internal 
structure. Conversely, Stack can access T 
and size, because it imports them, but can 
access no exterior variables. 

{Example of a module } 

{that implements a stack} 


type T -.. . 

const size:=10 

var Stack: 
module 

imports (T,size) 
exports (Push, Pop, Value) 
var storage: array L.size of T 
var fop: 0. . size 
procedure Push (v:T)= 

imports (var top, var storage) 

pre (top < size) 

begin 

tcp:=top+l 
storage(top):=v 
end push 


initially j 

I imports(var top) j 

j begin ; 

; top:=0 | 

i end | 

: end module i 

• ! 

Pascal provides a "while" loop which 
exits,at its top and an "until" loop that 
exits at its bottom. However, a loop cannot 
be exited from its middle (except by resort¬ 
ing to the famous goto statement). By com¬ 


parison, the loop construct in Concurrent 
• Euclid provides an explicit exit which can 
be placed as needed, for example: 
loop 

exit when x>y 
exit when x+y>z 
end loop 

The exit is put at the top when a "while" 
loop, and. in the middle as needed. Thus 
the loop of Concurrent Euclid is both more 
general and 'simpler than corresponding loops 
in Pascal. 

To summarize our comparison of Pascal 
and Concurrent Euclid, Pascal generally 
provides less efficient code while Concur¬ 
rent Euclid contains features that are more 
modern and that are needed for systems pro¬ 
gramming . 


CONCURRENCY 

’Operating systems control asynchronous 
devices and multiple users. The elegant 
and efficient way to handle these inter-ac¬ 
tions is via concurrent algorithms. These 
algorithms are relatively easy to write and 
maintain if.the programming language includes 
explicit features to support concurrency. 
Concurrent Euclid provides these features by 
means of concurrent processes and monitors. 
Monitors can be thought of as modules in 
which at most one process is active at a 
time. 

Neither Pascal nor C provides compar¬ 
able features, sc the systems programmer 
using these languages is forced to result 
to various unsavory tricks to gain the ef¬ 
fect of these features. 


! OBSERVATIONS 

Concurrent Euclid evolved as a language 
ifor highly reliable systems programming, 
iIt has borrowed and improved upon the eleg¬ 
ant features of Pascal. While doinq this 
; it- has maintained an efficiency that is 
jsuperior to proven lower-level systems lan¬ 
guages such as C. Clearly C is super..or to 
•assembly language. We believe that Concur- 
i rent Euclid is clearly superior to languages 
jlike C. 
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Second Distribution of Berkeley PDP-11 Software for XJMIX’f' 

(revised January 1981) 


A package of software for UNIX is available from the Computer Science Divi¬ 
sion of the University of California at. Berkeley. This package includes the 
instructional Pascal system, the editor ex, an improved Unix version 7 kernel, 
the INGRES database management system, and other software (some of which is 
described below). All user software except the editor will run without separate 
I/D space, and on both version 8 and 7 systems. 

Source code, binaries and machine readabln versions of all documentation 
are included with the tape, which is a standard tar format, 800BP1 magnetic 
tape. We will supply a magnetic tape on which the software will be written.*'If 
you do not have tar, a version 6 PDP-11 binary is on the tape and directions are 
given on how to extract it. The normal format for the tape is 8Q0BPI, blocked by 
a factor of 20 (1024-0 byte records). Thus you must have a working raw tape 
drive (/dev/rmtO) to be able to read the tape. Tp and cprio formats are not 
available. 1800BPI tapes are available upon special request. 

Binary only tapes, for holders of Unix binary licenses, are available for the 
same charge, containing PDP-11 v8 and v7 binaries, on an expressly as-is* ! wusupr 
parted basis. Binary wpes are not recommended, since holders of binary 
licenses are often on machines other than the PDP-11, or on PDP-11 without 
separate I/D (which is required to use ex/m) and because the inevitable prob¬ 
lems which require recompilation cannot be deait with, The sources to this dis¬ 
tribution cannot be distributed without a Unix source license because the editor 
ex and the shell csh, along with several other smaller programs, are based on 
version 8 Unix programs such as ed and sh. 

To receive the tape- fill out the attached agreement and send it. with 

1. A check fcr $150 USt made out to 

The Regents of the University of California 

2. A copy o; your UNIX license agreement.# 

3. A clear indication of your mailing address. 

4. A filled in copy of the agreement (which follows). 

to 

Berkeley Software Distribution for UNIX 

c/o Professor Susan L. Graham 

Computer Science Division, Department of EEC’S 

Evans Rail 

University of California, Berkeley 

Berkeley, California 94720 


fUNIX is a trademark of Bell Laboratories. 

*RK cartridge distribution of the software is not available. 

^Purchase orders Trill be accepted for a surcharge of $50 US to cover the additional process¬ 
ing involved. Please send a check if at all possible. 

#If you have a version 6 UNIX license and wish to receive the —me macro package and the 
modified version of the standard 1/0 library, then you must have (and include a copy of) a 
license for the version 7 phototypesetfer package. 
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Included with the tape are copies of all documentation for the programs on 
the tape. If you wish additional copies of the documentation, send $15 for each 
additional copy. (You can also get just the documentation; in this case you need 
only send $lb and a-copy of your UNIX license). Questions about this tape can be 
directed to Mark Horton at the address above or at (415) 642-4943. Messages 
can be left at (415) 642-1024. Arpanet mail can be sent to 2ted.@berkel.ey, and 
uucp mail can be sent to ucbvax!2bs& 

The tape also contains more recent versions of the csh, ex/vi, Mail, Pascal 
systems, and a few smaller programs, all intended for version 7. It is expected 
that these latest versions can also be run on version 6 with little or no work. 

This distribution is intended for the PDP-11. It will also probably run on 
other processors such as the VAX but there is a different (fourth) distribution 
which is more appropriate for the VAX. Inquiries about the fourth distribution 
should be directed to Laura Tong at the address above. 

The second distribution is continually being updated as new versions of pro¬ 
grams appear. It is aimed at vanilla version 6 and 7 PDP-11 systems. Programs 
included do not require the operating system, enhancements made at Berkeley. 


New Berkeley Software 

In addition to the Pascal system, the distribution tape includes programs 
such as the following. 

TkeXek' editor 

Two different versions of ex are included: versions 2 (currently 2,13) and 3 
(currently 3.8), Version 2 will (bareiy) fit on a PDP-11 .with separate 3/D and 
will run on a standard version S or version 7 system. Version 3 (the current 
production editor) is larger and requires either a VAX or the "user overlay" 
feature in.the supplied kernel. 

This version improves the terminal driving capabilities of the editor to pro¬ 
vide screen editing facilities using intelligent terminals. All terminal capa¬ 
bilities are described in a file so that the editor can drive new terminals 
after their descriptions are edited into the file. P adding and other require¬ 
ments of intelligent terminals are dealt with in the editor. The editor is 
particularly designed so as to be usable as a screen editor on low speed 
dialup lines with intelligent and unintelligent terminals. The size of the 
editing window can be made small, and will expand as you work. This 
prevents long delays, e.g. after a search when the -window will be redrawn in 
its smaller size. • 

The screen editing facilities of the editor have been extended so that it is 
possible to perform editing completely within "visual’' or "open” modes. 
Open mode has been extended so that it works on hardcopy terminals. 

Other new facilities include: 

—- Parameterless keystroke macros and word abbreviation. This facility 
allows a user who is repeatedly typing the same long sequence of com¬ 
mands or text to define a. keystroke or word abbreviation which 
expands into the long sequence. Keystrokes can be. any character or 
function key. Tnis facility is used to cause multi-character arrow keys 
to work. (The macro facility is available only in version 3.) 


52 


AUUGN 




- 3 - 


The capability to filter parts of the editor buffer through specified com¬ 
mands, and to re ad/write .parts of the buffer from/to command, 

“ Text registers into which, lines may be placed and carried over when 
editing new files. 

A tags facuity for editing large programs which are broken into many 
files. The editor can be told the name of a tag (usually a function 
name) and will then switch to the file where that"function resides and 
position itself ..at that function. 

fthile "ex” edits only one file at a time, it remembers the line position in the 
previous file, so that it is possible to easily switch back and forth between 
two files. 


An improved Kernel 

The source for a version of the Unix version 7 operating system is included 
on the tape,* This kernel is also expected to be a.vailabie'on the.San Fran¬ 
cisco Usenix tape. 


It contains a number of improvements over the Bell v? kernel. A number of 
performance improvements (such as hashing buffers, moving buffers and 
clists out of kemai space, and the IK block filesystem) have been made. 
’The kernel supports kernel overlays, allowing it to run on. non-separate I/D 
machines such as the PDP-11/23, It also supports user overlays, "so that ex 
version 3 can be ran, even on non-separate machines! 

lhe Berkeley tty driver is included, which correctly handles erase and kill 
characters on crt and printing terminals, including correctly backspacing 
over tabs and control characters., As of this printing, it is expected that the 
process control features of the Fourth Berkeley Software Distribution will 
be included. 


Changes to the kernel are conditionally compiled with mnemonic names, 
making it convenient to find the necessary changes to the kernel to imple¬ 
ment any given feature in your own kernel, and making it easy to turn on 
and off features you decide you do or do not want. This kernel was contri¬ 
buted to by, and includes, or will include, code from, the Fourth Berkeley 
Distribution, the U.S.G.S. system, and Tektronix. 

Hie Relational Database management system * 'INGRES’ * 

INGRES is a database management system presenting data as a collection 
of tables ( relations ). Facilities include the usual append, delete, replace, 
and retrieve, as well as a variety of database utilities including bulk load 
and store, dynamic storage structure reconfiguration, full crash recovery, 
data integrity controls, views, and macros. 


INGRES requires separated I?D space and floating point hardware. The ver¬ 
sion on the tape is aimed at Version 7 PDP-11 systems, although it is 
expected that a few cornpiltion flags couid be changed allowing it to work on 
Version 8 systems. 

A shell "csh." 


This shell incorporates good features of the earlier shells, previous Berkeley 
shells and the version 7 shell. It also has a history mechanism (similar to 
that of INTER3JSP) so that previous commands can be repeated and/or 
corrected. 


*In order to receive the kernel you must have a version 7 license. 
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Aa error message understanding program “error" 

This program looks at the output from a program compilation generated by 
Tnakp, or a compiler, inserts the error messages as comments into the pro¬ 
gram or programs affected at the proper point in the program, and invokes 
the editor on those files, positioned at the first error. It understands the 
error messages generated by the 'Ritchie and Portable C compilers, lint, 
make, Berkeley Pascal, the vax assembler, the loader, and f77. The pro¬ 
gram obviates the need for writing errors down on scraps of paper before 
entering the editor. Several useful interactive options exist. 

A macro package for nroff/troff: -sue 

This macro package is easy to use and especially easy to adapt to different 
formats. It works both with nroff and troff and provides a large number of 
hooks for special requirements. A beginners introduction and a reference 
manual are also available.! 

A "Mail” program 

This mail program uses "mail" to do the actual mailing and concentrates on 
providing a simple and friendly environment for processing large amounts 
of mail. 

The Berkeley Network 

The Berknet provides'a facility for file transfer between machines, network 
mail, and remote execution of commands, in a batch request fashion. It is 
used at Berkeley to connect a network of UNIX systems. It can be run using 
terminal ports to connect machines. 


flf you have a version 6 UNIX license and wish to get the -me macro package and the “stdio” 
modifications, you must include a copy of your license for the version 7 phototypesetter 
package; 
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Documents Supplied with the Tape: 

Vi Quick Reference Card 

An Introduction to Display Editing With Vi 

Edit: A Tutorial 

Ex Reference Manual 

Ex Differences: Version 1.1 To 2.0 

Ex/Edit Command Summary 

An Introduction to the C Shell 

Mail Reference Manual 

Writing Papers -with Nr off Using —me 

—Me Reference Manual 

Berkeley Pascal User’s Manual 

An Introduction to The Berkeley Network 

Network System Manual 

Screen Updating and Cursor Movement Optimization: A Library Package 
INGRES version 6.3 Reference Manual 
A Tutorial on Ingres 

Creating and Maintaining a Database Using Ingres 
Setting up Unix. - Berkeley/USGS Version 7 
New USGS/UCB System. Details 

Manual sections for all programs on the tape are also provided. 
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THIS LICENSE AGREEMENT is made and entered into this_day of 

__ , 19_, by and between THE REGENTS OF THE UNIVERSITYOF CALI¬ 
FORNIA, a. California corporation, hereinafter called "LICENSOR", and 

—--—___ > a __:_having its principal office at 

____, hereinafter called "LICENSEE"; 

WITNESSETH: 

WHEREAS, WESTERN ELECTRIC COMPANY, INCORPORATED ("WESTERN") is 
the proprietor and owner of the UNIX Time Sharing System, the UNIX Time Sharing System, 
Seventh Edition, or the PWB/UNIX Time Sharing Operating System, Edition 1.0 ("UNIX"); 
and 

WHEREAS, LICENSOR is the proprietor and owner of enhancements and additions to 
UNIX, which together with UNIX comprise computer programs and documentation entitled, 
“Second Berkeley Software Distribution ("Licensed Material")”; and 

WHEREAS, LICENSOR has been authorized by WESTERN to distribute the Licensed 
Material to licensees who are also WESTERN’S licensees for UNIX; and 

WHEREAS, LICENSEE warrants and represents that it is a WESTERN licensee for 
UNIX; and 

WHEREAS, LICENSEE desires to obtain from LICENSOR, and LICENSOR desires to 
grant to LICENSEE, a license to use the aforementioned computer programs and documenta¬ 
tion; 

NOW, THEREFORE, in consideration of the mutual covenants, conditions and terms 
hereinafter set forth, and for other good and valuable consideration, LICENSOR hereby leases 
to LICENSEE the Licensed Material, the components of which are described on annexed 
Schedule A, subject to a non-transferable, nonexclusive license ("License"), which is hereby 
granted to LICENSEE, io use such Licensed Material upon the terms and conditions 
hereinafter set forth; and LICENSEE hereby accepts such lease subject to the License solely 
upon such terms and conditions. 

1. Term. The term of this Agreement shall commence on the date hereof, and, unless 
sooner terminated as hereinafter set forth, shall extend indefinitely. 

2. Fees. The fee for this license and one physical copy of the Licensed Material is one 
hundred fifty dollars ($150.00). LICENSEE may obtain additional copies of the Licensed 
Material and copies of new releases of the Licensed Material which the LICENSOR may make 
available by paying a duplication fee of one hundred fifty dollars ($150.00) per copy. All such 
copies shall be subject to the terms and conditions of this agreement. All fees are due and pay¬ 
able in advance. 

Such fee does not include local, state or federal taxes, and LICENSEE hereby agrees to 
pay all such taxes as may be imposed upon LICENSEE or LICENSOR with respect to the own¬ 
ership, leasing, licensing, rental, sale, purchase, possession or use of the Licensed Material 

3. Maintenance and Update Services. Neither maintenance services nor update ser¬ 
vices are included in this Agreement. As used in the Agreement, the term "maintenance ser¬ 
vices" includes notice to LICENSEE of latent errors in the Licensed Material and rectification 
thereof. 




4. Title. LICENSEE agrees that the Licensed Material is, and shall at ail times remain, 
the property of LICENSOR. LICENSEE shall have no right, title or interest therein or thereto 
except as expressly set forth in this Agreement. 

5. Duplication and Disclosure. LICENSEE ?.nd LICENSOR agree that the Licensed 
Material contains proprietary UNIX Operating System Software. belonging io WESTERN and 
licensed by WESTERN as part of UNIX. LICENSEE represents that it has obtained a valid 
license from WESTERN to use UNIX and has provided a copy of this license to LICENSOR. 
LICENSEE agrees to treat WESTERN’S included proprietary software in the same manner as if 
such included proprietary software had been received directly pursuant to LICENSEE’S UNIX 
license from WESTERN. It is agreed that should the LICENSEE’S UNIX license from 
WESTERN be modified, for example, to include additional CPU’s, the modified license will 
govern the use of the Licensed Material. LICENSOR need not be notified of such 
modifications. Likewise, it is agreed that if LICENSEE’S UNIX license from WESTERN is ter¬ 
minated, LICENSEE’S license from LICENSOR is also terminated. 

LICENSEE may license the use of the Licensed Material to third parties provided that 
such licensing is acceptable to WESTERN. Material so provided may be either modified or 
unmodified. LICENSEE may, but need not, charge a fee for such licenses. LICENSOR need 
not be notified of such licensing. 

6. Proper Credit and Recognition. In the use and/or distribution of the Licensed 
Material, LICENSEE will take all reasonable measures to give appropriate credit to The Regents 
of the University of California and the Electrical Engineering and Computer Sciences Depart¬ 
ment at the Berkeley Campus of the University of California for their roles in the development 
of the Licensed Material, and shall make this condition a requirement of any agreement by 
which LICENSEE distributes the Licensed Material. 

7. Warranty and Limitation of Liability. LICENSOR MAKES NO WARRANTIES, 
EITHER EXPRESS OR IMPLIED, AS TO ANY MATTER WHATSOEVER, INCLUDING 
WITHOUT LIMITATION, THE CONDITION OF THE LICENSED MATERIAL, ITS MER¬ 
CHANTABILITY OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. 

LICENSEE agrees to indemnify, defend, and hold harmless LICENSOR, its agents, 
officers, and employees, either in their individual capacities or by reason of their relationship to 
LICENSOR, and its successors, in respect to any expense, claim, liability, loss or damage 
(including any incidental or consequential damage) either direct or indirect, whether incurred, 
made or suffered by LICENSEE or by third parties, in connection with or in any way arising out 
of the furnishing, performance or use of the Licensed Material. LICENSEE’S obligations under 
this paragraph include, but are not limited to, its obligation to indemnify, defend, and hold 
LICENSOR, its agents, officers, and empioyees harmless in the case of any claim of copyright 
or patent infringement based in any manner on LICENSEE’S use of the Licensed Material. 

8. Legal Expenses, In case legal action is taken by either party to enforce this Agree¬ 
ment, all costs and expenses, including reasonable attorney’s fees, incurred by the prevailing 
party in exercising any of its rights or remedies hereunder or in enforcing any of the terms, 
conditions, or provisions hereof shall be paid by the other party, 

9. Severability. If any part, term or provision of this Agreement shall be held illegal, 
unenforceable or in conflict with any law of a federal, state or local government having jurisdic¬ 
tion over this Agreement, the validity of the remaining portions or provisions shall not be 
affected thereby. 

10. Governing Law. This Agreement shall be construed and enforced according to the 
laws of California as applied to contracts made and to be performed in California, if LICEN¬ 
SEE is located outside the United States of America, the parties hereto agree that any dispute 
arising in connection with this agreement will be settled by the ICC Court of Arbitration. 

11. Paragraph Headings. The headings herein are inserted for convenience only and 
shall not be construed to limit or modify the scope of any provision of this Agreement. 
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12. Entire Agreement. This Agreement contains all the agreements, representations, 
and understandings of the parties hereto and supersedes any previous understandings, commit¬ 
ments or agreements, oral or written. 

13. Authority. Each of the undersigned warrants that he/she has the authority to bind 
to this Agreement the party which he/she represents. 


IN WITNESS WHEREOF, the parties hereto have executed this Agreement as of the day 
and year first above v/ritten. 


THE REGENTS CF THE 
UNIVERSITY OF CALIFORNIA 
(Licensor) 


By 


(Title) 


(Licensee) 


By 


(Title) 
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Berkeley Software for UNIXf on the YAXj 
4. Ibsd version of-May, 1981 


A new version of the UNIX system for the VAX family of computers is available 
from the Computer Systems'Research Group of the University of. California at 
Berkeley. This is an updated package of software for UNK732Yf licensees, and 
includes a refined version of the paging kernel for the VAX as well as a large 
number of other programs. This document describes the major differences 
between standard UNDC/3ZV as distributed by Western Electric and the May, 1981 
distribution known as 4.1BSB. 

The new relee.se may be used in two ways: as a bootstrap system for new 
hardware (or to bootstrap systems which were previously running 3bsd or 
UNIX/32V), or to update a system running the 4bsd release of November, 1980 
(now called 4.0bsd). Hardware configurations supported for booting are 
described below and in the document "Installing and operating 4.1bsd". The 
things most notable for sites which are updating 4.0bsd to this new release are: 

1 } Additional hardware support, including a number of new mass storage peri¬ 
pherals, and especially support for the VAX 11/750. 

2) Performance enhancement to the paging portion of the system, which 
should provide additional throughput in virtual-memory intensive environ¬ 
ments. 

3) A number of bug fixes. Most of the bug fixes are minor, but several irritat¬ 
ing bugs were present in 4.0bsd; this distribution, when used as an update, 
attempts to correct the known bugs while introducing few new ones. 

4 ) The INGRES data base system, developed at Berkeley by the INGRES pro¬ 
ject, is nov/ supplied with the standard system.. f 


System facilities 

Hardware support 

The system runs on VAX 11/750 and-VAX 11/7B0 processors and supports 
the standard TEC mass storage peripherals: RM03, RM05, RP08, RP07, RM60, and 
RK07 disks; TS11, TEK3, TU45 and TU77 tapes. BEC standard bad block handling 
on disk drives is supported on all the DEC disks except the RP08. The EMULEX 
SC21-V UNIBUS storage module disk controller is supported with AMPEX and-CDC 
300 Megabyte disk drives and FUJITSU 180 Megabyte Winchester drives. The 
EMULEX TOXI tape controller (which emulates a TM-11 DEC UNIBUS controller) 
is supported with tape drives such as the KENNEDY 9300. Any supported disk 
plus a tape drive is -sufficient io bootstrap the system on either processor. Two 

fUFK and UNIX/32V ere trademarks of Bell Laboratories. 

$YAX and PDP are trademarks of Digital Equipment Corporation. 
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drives are required for operation of the system using RKQ7's. Most RKQ7 sys¬ 
tems have no tape media, and so we can supply a distribution on two RK07 
packs. 

For terminal interfaces, in addition to the standard (non-DMA) DEC DZ-11 
terminal interface, (DMA) DH-11 emulators are supported for terminal support, 
such as the ABLE DH/DM (which replaces the ABLE DM AX). The system also pro¬ 
vides support for standard line printer interfaces emulating the DEC LP-11 and 
the use of 1200 baud terminals such as a DECWRITER-III acting as a slow speed 
printer. Printer-plotters such as made by BENSON/VARIAN or VERSATEC are 
also supported with standard drivers. 

Unlike previous releases of the system, this release supports any number of 
any of these devices. The devices may be placed arbitrarily on any available 
MASSBUS and UNIBUS interfaces. The system configures at boot time, locating 
available devices, using a system configuration compiled into the kernel. The 
configuration description contains all the information about the topology of the 
machine ana the addresses at which the various devices are located. It is possi¬ 
ble (and desirable) to write the description using "pattern matching" to only 
partially specify some of the interconnects. 

The system configuration program sizes system data structures based on a 
specification of the maximum number of active users to be present on the sys¬ 
tem. To build a system for a larger or smaller workload you only need change 
this single constant. The system also now initializes the parameters to the pag¬ 
ing system and sizes its file system buffer cache based on the amount of avail¬ 
ablememory; it is no longer necessary to adjust these by hand. 

The system supports access to the 11/780 console floppy disk; currently 
hardware (interrupt latency) problems prevents use of the 11/750 console 
cassette tapes; we hope to resolve this soon. 

For further information on device support and recommendations for 
configuration of VAX systems to run UNIX see “Hints on configuring a VAX to run 
UNIX’ 1 by Bob Kridle and Bill Joy. 

System reliability and performance 

The system reboots automatically after hardware and software failures, 
running an automatic procedure that recovers from normal minor disk incon¬ 
sistencies. If hardware or software failures cause unexpected problems on the 
disks, then an interactive semi-automatic repair program can be used to fix up 
the disks. 

The system is fully and transparently demand paged. As distributed it will 
support individual process sizes up to 6 Megabytes each of data and stack area 
and 6 Megabytes of program. These numbers can be increased on systems wil¬ 
ling to dedicate increased disk space for paging the process image. 

The default loader format is load-on-demand, and allows large processes to 
start quickly A vfork system call allows a large process to execute other 
processes without copying its data space. 

The system performance has been enhanced in a number of ways. Relative 
to UNIX/32V, the basic system overheads have been reduced by tightening up the 
system code and improving system data structures. Disk throughput has been 
increased by increasing the logical block size on the disks to 1024 bytes.* File 
system performance may also be increased, beyond that normally obtained with 
UNDC/32V or the 4.0bsd release, by properly interleaving the file systems to 
account for device speed; instructions on this and proper interleaving constants 
are given in the setup instructions for the system and in the rnkfs(B) manual 
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page.f System algorithms such as the snapping and file system caching algo¬ 
rithms have also been improved to increase system performance. 

Since the 4.0bsd (previously known as 4bsd) distribution of November, I960, 
performance of the system under heavy' paging load has been substantially 
improved by correcting a problem with placement of pre-paged pages. The sys¬ 
tem now pre-pages more data, greatly benefiting processes which have locality 
in their behavior. System degradation due to pre-paging and lock-out of other 
processes during heavy paging has been greatly reduced (even though more 
pre-paging is donej.f. 

Since the 4.0.bsd release, facilities have also been added for processes which 
serially reference large amounts of virtual memory to inform the system of this 
kind of paging behavior.. This helps the system to deal with these kinds of 
processes, which are not as well served by using the current default paging algo¬ 
rithm. Processes which are known to need only a small amount of memory but 
which tend to accumulate large amounts of memory due to strange page 
referencing patterns may declare a soft limit on the amount of memory to be 
used4 

For further information on system performance and recent measurements 
see the (revised) paper “Performance of UNIX on the VAX” by Bill Joy. 

What this distribution does not contain 

A number of new system facilities are under development at Berkeley and 
will be included in future releases of the system. We mention them here mostly 
to point out that they are not in this system: 

1) Arpanet TCP/IP support. This is being developed at BBN, and will be 
integrated into the system very shortly; if you need this right away, you 
should contact Alan Nemeth at BBN, 

2) Local network support. 

3) Inter-process communication support, providing facilities for user 
processes to take advantage of the network support and for writing 
cooperating user processes. 

4) Shared-segment access to large files, mapped in virtual memory. 

5 ) Performance changes for the file system to provide a higher access rate for 
applications which are currently i/o bound, of very large scale image pro¬ 
cessing. 

Development of the system in these areas is currently undervfay. The facili¬ 
ties should become available in roughly the order listed above. The design for 
these new facilities is spelled out in other documents available from our group. 


t Systems that roil UNK/ssv convert to the new format lr/ saving files using the tape archiver 
and reading them into the new system. Because of the' ormat changes in the file system and 
because some of trie changes described here required recompilation of all programs, a 

bootstrap tape and all. programs ore distributed. . 

t The actual change here is to place the pre-paged pages at the bottom of the memory free 
list, rather than putting them into the systems global "deck” replacement loop. This is a 
very minor change, but has significant performance implications. 

$ if the system, needs memory and there are processes which are over their declared limits, 
the system tends to take pages from these processes first. 
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User Software 


The following sections detail additional user-level software available with 
this distribution; we describe only software which is not part of the UNIX/32V dis¬ 
tribution. Full documentation and source for this (and all supplied) software is 
made available with the distribution. - 

Languages for the YAX 

Interpreters for APL, LISP and both an interpreter and compiler for Pascal. 
The APL interpreter is the PDP-11 version, moved to the VAX and has not been 
extensively used.* The LISP system, known as “Franz Lisp.*', is written in C and 
LISP, includes both an interpreter and a compiler, and is compatible with a large 
subset of MACLISP. The Pascal system is the instructional system that has been 
distributed previously for PDP-ll’s. The language implemented is standard Pas¬ 
cal. The implementation features excellent diagnostics, and allows separate 
compilation and use of C and FORTRAN procedures with full type checking. 

A display editor 

The tape includes the display editor, vi, (vee-eye) that runs on over 100 
different intelligent and unintelligent display terminals. This editor uses a ter¬ 
minal description data base; a library of routines for writing terminal indepen¬ 
dent programs using this data base is also supplied. The editor has a mnemonic 
command set that is easy to learn and remember, and deals with the hierarchi¬ 
cal structure of documents in a natural way. Editor users are protected against 
loss of work if the system crashes, and against casual mistakes by a general 
undo facility as well as visual feedback. The editor is usable even on low speed 
lines and dumb terminals. 

Command and mail processing programs 

The tape, also includes a new command processor csh that caters to interac¬ 
tive users by providing a history mechanism so that recently given commands 
can be easily repeated. The shell also has a powerful macro-like aliasing facility 
that can be used to tailor a friendly, personalized, command environment. A 
new interactive mail processing command supports items such as subject and 
carbon, copy fields, and distribution lists, and makes it convenient to deal with 
large volumes of mail. 

Job control facilities 

The system now supports the multiplexing of terminals between jobs. It is 
no longer necessary to decide in advance that a job is to be run in the fore¬ 
ground or background; running jobs may be moved from the foreground to the 
background and vice-versa, and mechanisms exist in the C shell csh for arbitrat¬ 
ing the terminal between the active jobs. 

Debugger support 

A version of the symbolic debugger sdb is included in the distribution that 
can be used to debug Pascal, C, and FORTRAN 77 programs. The assembler has 
been rewritten and the C compiler modified to reduce greatly the^overhead of 
using the symbolic debugger, 

• A number of groups are working on improved versions of the APL interpreter, and we hope to 
obtain a better version of APL soon. 
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Other software 

Also included are several other useful packages including programs to 
simulate the phototypesetter on 200 bpi dot-matrix plotters (these programs 
were moved from the PDP-11 to the VAX and many fonts available on the.Arpanet 
have been converted to the required format), a bulletin board program, routines 
for data compression, a slow-speed network for connecting heterogeneous UNIX 
systems at low cost (1 tty port per connection per machine and no system 
changes), and a new, flexible macro package tor nr off and trajj called ■ me. 
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LICENSE AGREEMENT 


THIS LICENSE. AGREEMENT is made and entered into this ___ day of 

, 19 __ , by and between THE REGENTS OF THE UNIVERSITY Or CALI¬ 

FORNIA, a California corporation, hereinafter called "LICENSOR", and 

a __having its principal office at 

’ . hereinafter called "LICENSEE"; 


WITNESSETH: 

WHEREAS, WESTERN ELECTRIC COMPANY, INCORPORATED ("WESTERN") is 
the proprietor and owner of the UN1X/32V Time Sharing System, Version 1.0 ( UNIX ), and 

WHEREAS , LICENSOR is the pj.prielor and owner of enhancements and auditions to 
UNIX, which together with UNIX comprise computer programs arid documentation entitled. 
“Fourth Berkeley Software Distribution ("Licensed Material")”; 2 nd 

WHEREAS. LICENSOR has been authorized by WESTERN to distribute the Licensed 
Material to licensees who are also WESTERN’S licensees for UNIX; and 

WHEREAS, LICENSEE warrants and represents that it is a WESTERN licensee for 
UNIX; and 

WHEREAS. LICENSEE desires to obtain from LICENSOR, and LICENSOR desires to 
gram to LICENSEE, a license to use the aforementioned computer programs and documents* 
lion; 

NOW, THEREFORE, in consideration of the mutual covenants, conditions and terms 
hereinafter set forth, and for other good and valuable consideration, LICENSOR hereby leases 
to LICENSEE the Licensed Material, the components of which are described on annexed 
Schedule A, subject to a non-transferabie, nonexclusive license ("License"), which is hereby 
granted to LICENSEE, to use such Licensed Material upon the terms and conditions 
hereinafter set forth; and LICENSEE hereby accepts such lease subject to the License solely 
upon such terms and conditions. 

1. Term. The term of this Agreement shall commence on the date hereof, and. unless 
sooner terminated as hereinafter set forth, shall extend indefinitely. 

2 . Fees. The fee for this license and one physical copy of the Licensed Material is three 
hundred dollars (S300.00). LICENSEE may obtain additional copies of the Licensed Materia! 
and copies of new releases of the Licensed Material which the LICENSOR may make available 
by paying a duplication fee of three hundred dollars (S300.00) per copy. All such copies shall 
be subject to the terms and conditions of this agreement. All fees are due and payable in 
advance. 

Such fee does not include local, slate or federal taxes, and LICENSEE hereby agrees to 
pay al! such taxes as may be imposed upon LICENSEE, or LICENSOR with respect to the own¬ 
ership, leasing, licensing, rental, saie, purchase, possession or use of the Licensed Materia . 

3 . Maintenance and Update Services. Neither maintenance services nor update ser¬ 
vices are included in ibis Agreement. As used ir the Agreement, the term ’’maintenance ser¬ 
vices" includes notice to LICENSEE of latent errors in the Licensed Material and rectification 
thereof. 

4 . Title. LICENSEE agrees that the Licensed Materia! is, and shall at all times remain, 
the property of LICENSOR. LICENSEE shall have no right, title or interest therein or thereto 
except as expressly set forth in this Agreement. 
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5. Duplication “ d ^longtn^i^^XSTERN^d 

S “STERN a S pVolUNlX. ^jep^nu^|-~NS^ 

license from WESTERN tc> use UK - a d prielary software in the same manner as if 

LICENSEE agrees to treat W cSTtaP^K s m lud.d prop^^ari ^ |o LICENSEE'S UNIX 

such included proprietary software Mb - ^ UCENSE£ . s W 1X license from 

license from \\ cSTt-RN. It is ag.e-^ . . , rpi iv -the modified license will 

WESTERN be modified, for example. to include .d<Mmn.l CPU s^the moo ^ ^ 

govern the use of the License . ia jc^sef^ \JK1X license from WESTERN ts ler- 

» ^^terminated. 

UCENSEE may iicense the use of the Licensed 

~ ■ r “'»- llOT - 

not be notified of such licensing. ■ diM ribution or the Licensed 

6 Proper Credit and Recognition, in uw use and/ - to The Regents 

Material. L1CFNSEE will take all Computer Sciences Depart- 

of the Universuy <>f C^tfomw and he J 1 California for their roles in the development 

KVS M«e^.nd^ll make this condition a requirement of any agreement by 
which LICENSEE distributes the Licensed Maienal. N0 WARRANTIES. 

EITHe’r » WS 

its . t . ws 

LICENSEE agrees to indemnify. 

officers, and employees, eitt er .n tht.r in 1 nse c!a j m , liability, loss or damage 

LICENSOR, and its successors, in re peel to an> w whether incurred, 

(including any incndemal pariils. in connection with or in any way arising out 

made or suffered by LlCuKS^. or o> ““l Materia] 1 ICENSEE's obligations under 

of the furnishing, performance or use of the be M ■ . d nify de f e nd. and hold. 

lhis paragraph include, but are no. itmHed 0 of ^ claim of copyright 

LICENSOR, Us agents, officers. and . eI "P 1o> LICENSEE'S use of the Licensed Material. 

Xf&g STS 8& SS > { -? * « » »«»* ■» - *• — 

sssr. •»*" « - *> *? * *« »w. 

9. Severability. If an y P art ' le!m , or provtsto . „ 0V ernment having jurisdic- 

srssiss: r sir * *****«******* a ° i * 

•'■tsi,, ™. * s »» ; « 

laws of California as applied to - America the parties hereto agree that any dispute 

SEE is located outswlii bTse.td by the ICC Court of Arbitral,on. 
arising tn connection *.,., h, ag - herein „ e Jnserte d for convenience only and 

11 . Paragraph "Headings. ’ JL f £n orov * 5sion of this Agreement. 

' shall no, be construed ,0 Itimt «"“*[> ‘ a „ lhe agreements, representations. 

12. Entire Agreement. . Tf f e -Ko and supersedes any previous understandings, commtt- 
and understandings of tne parties he.eto and supervenes a y v 

ments or agreements, ora! or written. 


A-cl uw . 


b*<L 











13. Authority. Each of the undersigned warrants that he/she has the authority to bind 
to this Agreement the party which.he/she represents. 


IN WITNESS WHEREOF, the parlies hereto have executed this Agreement as of the day 
and year first above written. 


THE REGENTS OF THE 
UNIVERSITY OF CALIFORNIA 
(Licensor) 


By 


(Title) 


(Licensee) 


By 


(Title) 
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Jane Poplawski 
Samuel H. Poraul 
Rich Ptak 
Isaac Rabinovitch 
Ernie Rael 


TRW 

Purdue University 
Hughes Aricraft Company 
Hughes Aircraft Co. 

Michigan State University 

US Army Development & Readiness Command 

Bell Labs 

Paradyne Corporation 
Bell Labs 

Hughes Aircraft Company 
University of Texas . . 

Harvard University 
University of Oklahoma 
Union Carbide Corporation 
Compug! aphic Corporation 
University of Oklahoma 
Hughes Aircraft Company 
Data General Corporation 
Bell Northern Research 
Bell I^abs 

University of North Carolina 

U. S. Army Ballistic Research Laboratory 

NCAR 

Veterans Ad m i n i s t r a t i o n / Se 1 ■ f - Era pi o ye d 

N. C. State University 

The University cf Texas 

Raytheon Data Systems 

University of Caifornia 

The MITRE Corporation 

Department of Defense 

AT & T 

Texas A & M University 
US Gov./Wright St ate Univ er sity 
University of Florida 
University of California, Davis 
BNR, Inc. 

NPRDC 

Digital Equipment Corporation 
The Rand Corporation 
Lawrence Berkeley Laboratory 
Lawrence. Berkeley Laboratory 
Lawrence Berkeley Laboratory 
University of Texas 
Docutel Corporation 
Computer Automation, Inc. 

The University of Texas 

University of Texas 

University of California, San Diego 

University of Texas 

ITT 

Digital Equipment Corporation 
University of California, Santa Cruz 
ONYX 
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Texas Usenix Conference 


23 June 1981 


John Rainey 
Edward Rathje 
Cathryn L. Ratzloff 
Brian E. Redman 
Dennis F. Reed 
Keith G. Regan 
Thomas C. Reinertson 
James Rhodes 
William M. Ricnards 
Dan Ritchie 
Chris Robertson 
Gary A. Roedigcr 
Ed Rupp 
Jerome Sable 
Von Sagrillo 
Jonathan Haim Saks 
Louis Salkind 
Stanley S. Sehenker 
Debbie Scherrer 
Je ff Sc hriebman 
Michael Schueking 
German Schurnacher 
Ed wd r d W. Sc ott, Jr . 
Janies Seagraves 
John Seanions 
Norm Seethoff 
Bill Shannon 
Scott Sibley 
Greg Siebers 
Roger J. Sippl 
Chester G. Skapczynski 
Tom Slezak 
Steven Small 
Dennis R. Smith 
Henry Spencer 
Earl Stahl 
Barbara Staudt 
Jeff Stearns 
Armando P. Stettner 
Peter Stevens 
W. Ri c ha rd St ev en s 
Pam Stevenson 
John Stier 
James Stolpa 
James Stolpa 
Daniel R. Strick 
Torn Strong 
Daniel M. Sunday 
Kenneth P. Syrup son 
Andrew Tannebaum 
Cheryl Taub 
Bruce M. Taylor 
Judy Terrill 


Ford Aerospace 

JMI So f twar e Co nsul tan t s, In c . 

TRW Vidar 
BTL 

Storage Technology Corporation 
COMSAT Corporation 
T IS OFT, Inc,. 

N a t i o n a 1 In s t r urn e n t s 
ABACUS 

Department of Defense 
University of Toronto 
Corporate Computer Services 

RCA Laboratories 

Martin Marietta 

MIT — Lincoln Laboratory 

Ne w Yo rk Un iv er si t y 

Codex Corporation 

Lawrence Berkeley Laboratory 

Jeff Schriebman Consulting 

University of Texas 

Cerro Tololo In teramerican Observatory 
Computer Consoles, Inc. 

Bell Labs 
Luc asfilm, Ltd. 

John Fluke Mfg. Co. 

Digital Equipment Corporation 
Ford Aerospace 
CACHE Corporation 
Relational Database Systems, Inc. 

TRT Telecommunications Corporation 

Lawrence Livermore National Lab 

Un iq Co m p ut e r Co rporation 

USC - Information Science Institute 

University of Toronto 

Bell Northern Research 

Moravion College 

John Fluke Mfg. Co. 

Digital Equipment Corporation 
Bunker Kamo Corporation 
Kitt Peak National Observatory 
MicroTrol Systems, Inc. 

State University of New York 
Hie University of Texas 
University of Texas 
University of Pittsburgh 
Strong Consulting 
Johns Hopkins University 
Computer Consoles, Inc. 

WEC/BTL 

American Institute of Physics 
Advanced Business Communications 
USARMY DARCOM * 
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Texas Usenix Conference 


?3 June 1981 


Dean Thomas 
Spencer Thomas 
Carolyn R. Thompson 
Nancy Thornton 
Michael D. Til son 
Abigail Tischler 
Daniel P. Tkach, Jr. 
Fr ed To th 
James Truchard 
Richard D. Tuck 
Lisa Lynn Turboff 
David R, Turner 
Ray Turner 
Richard G. Turner 
Bill Tuthi11 
Robert W. Tuttle 
Ro n al d W. Un d er wo od 
R. Uthurusamy 
Shirley Verrett 
Carl Vesper 
Roger Vossler 
Sue Wainer 
Justin C. Walker 
Charles R. Waltrip 
Dan H. Ward 
Charles H. Warlick 
Kirk Webb 
Wally Wed el 
Peter G. Weiner 
Gilbert Weingarten 
R. L. Weis 
Howard S. Weiss 
•Michael L. Wend el 
Wentworth 
Anna M. West 
Dorothy Anne Whitaker 
Dr. James C. Whitney 
Norman Wilson 
David G. Wiseman 
Robert Worls 
Amanda Wright 
Joseph S. D. Yao 
Brian Yasaki 
Chris Yeung 
David Yost 
Alan 2aring 
P. A. Zinn 
Christine Zuest 
Mike Zuhl 


Santa Cruz Operation 
Un iv er si t y o f Ut a h 
Johns Hopkins University 
■Geotronics Coporation 
Human Computing Resources Corporation 
Co 1 urnbia University 
Uniq Computer Corporation 
Washburn Press 
Nation?:! Instruments 
Hewlett-Packard 
The University of Texas 
EG Sc G, Idaho 
Genrad 

USARMY DARCOM 
University, of California 
General Electric Co. 

Bell Labs 

Exxon Production Research Co. 

The University of Texas 

Fischer &.Porter 

TRW 

JMI Software Consultants, Inc. 
Interactive Systems Corporation 
Johns Hopkins University 
MicroTrol Systems, Inc. 

University of Texas 
University of Texas 
The University of Texas 
Interactive Systems Corporation 
AM Varityper 

Hughes Aircraft, Ground Systems Group 

Department of Defense 

General Instrument Coporation 

Ford Aerospace & Communications Corp. 

BBN Computer Corporation 

The MITRE Corporation 

Dictaphone Corporation 

Caltech 

University of Western Ontario 
Bolt, Beranek, and Newman, Inc. 
System. Industries 
Science Applications, Inc. 

I. M. S. 

Microtel Pacific Research 

University of 
Hughes Aircraft Company 
USARMY DARCOM 
Tektronix, Inc, 
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Nearly all computer users store information on disks, modify it 
regularly, and wish to query it and have reports written from it. if the 
application is very common, such as payroll, a packaged program 
may be available to perform these tacks. However, most user’s 
requirements have a great deal of uniqueness. For example, a blood 
bank’s supply tracking needs probably won’t be satisfied by the 
capabilities of a ready-made inventory control package. In fact, many 
companies inventory control requirements are not met by the 
capabilities of any pre-programmed packages. Some customization 
is usually needed, and that means programming. If no package is 
available at all, the amount of programming needed to start from 
scratch is often prohibitive. 

Many consultants, system designers and programmers are turning to 
UNIX to increase their custom programming productivity. UNIX 
provides not only a pleasant environment for software development, 
but also provides a wide variety of programs that are already written, 
and designed to work together. Programmers are using these off-the- 
shelf components to build custom systems without starting 
completely from scratch. By doing this they are cutting their costs 
and increasing their productivity enormously. 

MARATHON is a collection of such programs designed to aid the 
building of single or multi-user applications on UNIX, UNIX look-a¬ 
like and UNIX-compatible operating systems. MARATHON’S 
components include an interactive query language, an interactive 
data entry and maintenance program, several report writers, audit 
trail and recovery programs and all the utilities needed to create, 
optimize and modify databases. 

This set of tools is so flexible and complete that many simple 
applications need only be configured, and not programmed at all. For 
situations where detailed customization is a must, pov erful 
interfaces to standard programming languages are naturally part of 
the system. 

MARATHON is the first commercial DBMS for UNI).. It is not based 
upon any particular academic system or commercial prototype, but 
rather it draws from the best features of ail of them. The sole reason 
for its existence is the commercial UNIX user, and the design and 
future directions of the product reflect this. 

Good documentation, error messages, enhancements, host language 
compatabiiity, training and support are all expected by commercial 
users. RDS is committed to helping system des f gners and 
programmers cut the costs and heighten the reliability and 
expandability of their applications. The MARA T'HON system and its 
report writers are the base for that help. 

No application shouid be built for UNIX starting from scratch. Any 
data intensive software system should include the data manipulation 
and maintenance functions provided by MARATHON. Systems 
designers and applications programmer? owe it to their users to start 
building an application with a firm foundation. 


1208 Apollo Way. Suite 503 
Sunnyvale, California 94086 
Telephone 408/746 0982 
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agement System 



A NEW RELATIONAL DATABASE MANAGEMENT SYSTEM 
DESIGNED BY THE CREATORS OF MRS 


READILY CUSTOMIZED, FULLY MAINTAINED, 
EXTENSIVELY SUPPORTED 


y* r. if o ta C 1 O' 
X\' JB. K O A A V -O O 


WRITTEN AND IMPLEMENTED USING 
FULL SOFTWARE ENGINEERING PRINCIPLES - 
MODULAR DESIGN, TOP-DOWN PROGRAMMING, 
TRANSPORTABLE CODE 


7a /fi T'-fX r OTy IP O' p 
i f 4. Ji. Of ii iri JLj O' O 

DOWNWARD-COMPATIBLE WITH THE MRS 
QUERY LANGUAGE 


‘• 1 T'Tv.r 

rlLlS. 


AL 


A 

i‘k 




© 

© 

© 


a superset of the English-like Query Language used in MRS 
a host-language interface via “C” callable procedures 
restrictions on the numbers of tuples and attributes removed 
an ongoing program of enhancement and development 
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® more data types: 

several varieties of character strings 
3 kinds of integers: 8, 16, and 32-bit 

2 kinds of floating point: 32 and 64-bit 

3 formats of date data type 

dollar data type for commercial users 


IONS PACKAGES 


A number of applications packages are currently under development. These include: 
® report generator 
© screen oriented forms interface 

© transaction processing system 


Other packages are being designed for future release. Custom applications and other 
services will be undertaken on request at negotiable rates. 


MISTRESS is designed to run on most existing PDP-11 and LSI-11/23 configurations 
under the Unix ‘ operating system (V7, PWB or V6). In addition, it is targeted for 
other configurations and operating system environments. 


MISTRESS is sold under both standard and educational licences. A standard licence 
includes binaries, documentation, and one year’s support. Ongoing support is avail¬ 
able for a yearly fee. An educational licence, at a special price for non-profit academic 
institutions, includes only binaries and documentation, with no support. 


interested in acquiring a MISTRESS? Write to: 


RHODNIUS INC., 

Product in formation, 
P.O. Box i, Station D, 
Scarborough, Ontario 
NADA MIR■ 


For prompt service, telephone 


John Kornatowski 


Unix is a registered trademark of Western Electric 


AUUGN 


77 





The CGC 7900 is the newest member of the Chromatics line of The high resolution color monitor features 1024 x 768 viewable 
color graphic computers featuring state-of-the-art technology in dot resolution with a graphics memory of 1024 x 1024. A special 

a totaliy integrated package. The cGC 7900 Computer is color look-up table allows up to 256 colors to be displayed at 

designed for either stand-alone applications or may be con- one time with a color palette of over 16 million colors. A ter- 

nected via serial or parallel ports to a host computer. The new minal emulator provides access to a variety of standard 

Chromatics unit features a 16-bit processor, 19" CRT and the graphics primitives for generating characters, lines, arcs, 

internal capacity to hold both a 10AAB Winchester disk drive and circles, rectangles, triangles, polygons and curves as well as 

two double density flexible disk drives. The powerful set of providing a boundary fill for irregularly shaped closed objects, 

software options allows users to program in BASIC, PASCAL, C System flexibility is further enhanced through an eight color 

or Assembly language. The graphics flexibility combined with Overlay which utilizes character cell graphics to overlay an 

an abundant range of color capabilities provides every user image on a Bit Map graphics picture, totally unaffected by the 

with an unparalleled color graphic computer. graphics roll, pan or zoom of the underlying image. 



Processor 

Motorola MC68000 16-bil CPU with eight 
32-bit data registers, seven 32-bit address 
registers, and a 24-bit address bus capable of 
addressing 16MB of memory. 

Video Display 

A 19' CRT with 1024 x 768 viewable dot 
resolution featuring eight bezel keys located 
directly below the CRT. 

Keyboard 

151-key keyboard with 21 lighted keys for 
visual feedback, 24 programmable function 
keys and two-speed repeat on all keys. 

Color Look-up Table 

Maximum of 256 locations of 24 bits each 
(eight per color gun). Any color may be 
altered to any other color. Eight bit grey scale 
resolution in each of red, green and blue. 
Over 16 million possible combinations. 

Zoom 

Zoom to any integer level up to 16 in x or y 
direction, or both. 

Pan 

Allows users to pan to any area of 1024 x 
1024 Bit Map memory area. 

Fixed Disk Storage (option) 

10MB eight inch fixed disk drive, Winchester 
technology, integrated into the terminal 
cabinet. 

Flexible Disk Storage (option) 

Double density dual flexible disk drives pro¬ 
vide 1MB of removable storage. Provides 
back-up for fixed disk. 

Joystick (option) 

Three axis, used for zoom and x-y pan, cur¬ 
sor positioning and color change selection. 
Light Pen (option) 

Used to select, move or design objects 
directly on the display without keyboard 
interaction. 

Complex Sound Generator 
Produces three tones, noise and envelope. 
Programmable from keyboard. Quiet lock on 
keyboard silences speaker. 



IDRIS Multi-Tasking Operating System 
(option) 

A general purpose multi-tasking operating 
system designed to operate on a MC68000 
16-bit processor. The IDRIS Operating System 
is written in the C language and includes an 
assembler and text editor. Both C and PASCAL 
compilers are supported under IDRIS. 


IDRIS comes with a highly interactive shell 
supporting shell scripts, filters, pipes, I/O 
redirection and redirection of error 
messages. Any number of background tasks 
can be initiated by separating commands 
with the symbol. Features include a 
hierarchical file system, read, write and exe¬ 
cute permissions, and compatible file and 
device I/O. IDRIS also features C callable 
primitive routines including OPEN, READ, 
WRITE, LSEEK, FORK, PIPE, EXECL, EXIT, 
WAIT and CLOSE. 

Disk Operating System (DOS) (option) 

A general purpose disk operating system 
designed to provide an interface between 
the CGC 7900 computer and the disk based 
mass storage system. The DOS will support a 
BASIC Interpreter as well as a 68000 
Assembler and Text Editor. 



Graphic Plotting 

Enables software generated vectors, con¬ 
catenated vectors, incremental vectors, incre¬ 
mental x-bars, incremental y-bars, polygons, 
circles, rectangles and triangles. 

Windows 

Up to eight individually addressable windows 
in Bit Map and/or Overlay memory. 

Extended Plotting Software (option) 

Provides four-point Bezier curve, ray, arc and 
selectable bold vector in Bit Map. 

Complex Fill (option) 

Provides fill routines for complex area fill and 
tile (polygon) fill. 

Raster Processor Graphics (option) 

Handles transfer of rectangular sets of pixels 
from one area of Bit Map memory to another. 
Supports right angle rotation, mirrorng, 
inversion of images, color swapping, pattern¬ 
ing and soft zoom. 



User Memory 

128K standard, expandable in 123K modules. 
Bit Map Memory 

Available in 128K memory planes. One 
memory plane is standard with the Model 1 
Base Processor. Four memory planes are stan¬ 
dard with the Model 2 Base Processor. Expan¬ 
dable to 16 planes total, for fully buffered 
image memories. 


CMOS Memory and Real-Time Clock (option) 
Battery backed CMOS RAM provides non¬ 
volatile memory for system defaults even 
with system power off. Function key defini¬ 
tions, memory allocations, baud rates and 
buffer sizes ail remain in CMOS. Real-Time 
Clock set by user to display month, date and 


time. 



Serial 

One RS-232C and one RS-449 serial port is 
standard with every unit. Baud rates to 19.2K 
bps. Baud rate and word format selectable 
from keyboard or program. 

Parallel (option) 

Two 16-bit bidirectional parallel ports. One 
port is a DAAA type port compatible with the 
Digital Equipment Corporation DRV TT-B inter¬ 
face. This port is capable of transfering up to 
50QK bytes or words per second. The second 
port is a general purpose parallel port with 
polling and interrupt capabilities. The 
general purpose port is capable of indepen¬ 
dent input and output transfers. 



Size/Weight 


Height.53' 

Width . 22' 

Depth . 34' 

Weight....220 lbs. 

General 

Power—105-125V, 60 Hz, 1000 watts 
Temperature— 

+10° C to 40° C Operating 
— 30° C to 70° C Storage 
Humidity—0-95%, non-condensing 

CRT 

Screen Size—19' diagonal 
Refresh Rate—30Hz 
Resolution—1024 x 768 viewable 
Phosphor—long persistence 

Color Graphics 

Character Format—5 x 7 dot matrix, 

6x8 field 

Graphics Character Resolution— 

170 per line with 96 total lines, variable size. 
Overlay Characters—85 characters per line 
by 48 ! : nes 

Mass Storage 

Fixed Disk Capacity—10.67 MB 
(unformatted) 

Dual Flexible Disk Capacity—1.2 MB 
(formatted) 










Features 


'—130 packets/second full dupSax communication line throughput 

— Plus 200 packets/second full duplex host computer throughput 
■ — ARPANET network technology 

■— 135 ns powerful microprogrammable architecture • 

— Supports up to 6 X.21, X.21 (bis), Bi-Sync or ARPANET Sync Ports 

— Also supports up to 4 1822/ARPANET Host Ports 

— Also supports up to S4 Medium-spaed Async/Sync Terminals 
•— Self-conflgiislng on start-up 


SytllffUsfy • The C/30 packet .switch processor was designed specifically for high-speed communications environ¬ 

ments. A very fast, powerful, microprogrammed CPU architecture provides raw speed and basic com¬ 
munication instruction sets. 

, Much of the complicated 1-0 logic is performed by the central microprocessor which both reduces i-0 

component count by a factor of 3 or 4 and aiiows one basic 1-0 device to be microcode configured as 
many different devices. For example, the basic serial communications-line device can handle Asyn¬ 
chronous devices from 50 to 19,200 baud, with or without modem control. Synchronous, or Binary 
Synchronous devices up to 56 kbaud, ail by simply changing microcode. 

1-0 devices are supplied with several microcode routines to allow them to handle a variety of devices, 
A basic micro-assembler and micro-ioader are available as well. 

Optionally, the C/30 is supplied with the ARPANET Interface Message Processor software, or the 
ARPANET Terminal Interface Processor software. Tens of man-years have been invested in this code 
to allow it to operate the world’s biggest packet switch network. 



Central Processor 


SIS I 





The C/30 CPU is based around a fast microprogrammed CPU with an instruction set designed for 
communications environments. The basic elements are a Ik x 20-bit register file, a 512 x 32-bit 
microcode ROM containing the loader, debugger and console logic, and a microcode memory in sizes 
cf 2k, 4k or 8k x 32 bit which contains the macro-instruction set and 1-0 emulation. Microcode has the 
ability to lun in either the 16-bit or 20-bit mode at the macro instruction level. Microcode memory is 
loaded from a microcassette holding up to 10Okb. 

The BASIC C/30 also includes 2 serial async 1-0 ports, (one for the console terminal, the other for the 
micro-cassette loader), a 4-slot chassis with batten,' backup power supply, and 32k words of 20-bit 
405ns semiconductor memory. An Error Detection and Correction system is also standard. 

An EXPANDED C/30 provides an 8-slot chassis and larger power supply system. 

C/30 systems are provided with microcoded emulation of a minicomputer's Instruction set, providing 
simpie access to ARPANET packet switch network software. 


The 1-0 system is greatly simplified compared to most current minicomputers. Most C/30 1-0 devices 
consist of only voltage conversion devices, serial to parallel’ conversion, and a variably sized FIFO (first- 
in, first-out) buffer. All complicated logic is performed in the CPU. 

This approach produces low-cost 1-0 devices because yery little hardware is actually used, and one 
hardware design can function as many different devices by changing microcode. 

For example, a single design of serial communications port can support any kind of Asynchronous 
Device, with speeds from 50 baud to 19,200 baud; Synchronous Device, or Binary Synchronous 
Device with speeds to 56k baud. Different microcode is required, but this is kept in RAM memory 
(loaded from microcassette) and allows the system’s OEM to use a very small number of interface 
designs for a very large number of different applications. 

Most C/30 1/0 devices use small daughter boards to customize the voltage conversion for different line 
disciplines, for example, RS-23.2, Beil 303, RS-422, MIL-188-114, etc. 
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Memory 


oornmunications 

I 11 . U 'C^c Si £ iT# •aSr 


The C/30 includes the 32kw of 20-bit memory. Additional memory is available in sizes of 32kw. All 
memory is RAM, 405ns access time. Maximum memory is 128k words. 

Error Detection and Correction (EDAC) is standard. This provides 6 additional bits of checking, allowing 
detection of all single- and double-bit failures, and correction of all single-bit failures. 

C/30 Memory is currently based on 16k memory ICs. 


The C/30 has four basic communication 1-0 designs: 

• Medium-speed Async/Sync Interfaces • High-speed HDLC/SDLC Interfaces 

• High-speed Async/Sync interfaces * High-speed 1822/ARPANET Interfaces 

Each design has a number of daughter-boards, which provide voltage conversion as required and 
associated microcode to handle the interface for a specific line protocol. 

The following currently exist: 

® For Async Interface Design: 

- 20-ma current loop 

- EIA interfacing to terminals - EIA interfacing to modems (modem control 

(modem control not included) included) 

All of the above can handle devices at speeds of 50, 75, 110, 134.5, 300, 600, 900, 1200, 2400, 
4800, 9600, 19,200 baud. Full duplex, half duplex, S/6/7/8 bit data bytes, 1, 1 V 2 
and 2 stop bits, even/odd/none/marking parity are ail supported. 

. The microcode supplied includes the ability to support auto-speed detection. IBM 2741 terminals 
can also be supported. 

• For High-speed Async/Sync Design 

- Bell 303 modem support 

- RS-232C modem support 

- RS 422/423 modem support 

• For High-speed HDLC/SDLC 

- X 21 support 
® For 1822/Arpanet 

- Local 1822 Host support - Very Distant Host (VDH) support (same as 

- Distant 1822 Host support Bell 303). 

The various communication line designs are available on 14x18 logic cards in a variety of combina¬ 
tions: 

5401: 4 1822 Ports, 6 High-speed Async/Sync 

5410: 32 Async Ports, 1 1822 Port, 1 Sync/SDLC/HDLC Port. 

Fc r complete details, refer to the price list. 


MIL-188-114 support 
V.28 support 


V M lOf I'W UtSV 

Also available is a disk controller designed to handle up to 2 Storage Module Disk (SMD) drives. Many 
manufacturers offer a variety of disk drives that interface to the SMD bus. 

Power 

The BASIC C/30 requires 300 watts of power, which can be supplied at 115v or 230v, 
or 50 or 60 Hz. 

Physical Construction 

The BASIC C/30 fits in a standard 19-inch-wide rack and uses 12.5 inches of vertical space (20 inches 
deep). 

The microcassette occupies 31/2 inches of vertical space (12 inches deep). Most communication 1-0 
boards include connector panels that use 3 Vz inches of vertical space in the rear of the cabinet, nor¬ 
mally behind the microcassette. 

The EXPANDED C/30 requires M Z A inches of vertical space. All other dimensions are the same. 

Environmental - 

Operating: 2°C to 32°C, humidity 0-90% (noncondensing) 

Storage: -15°C to 65°C, humidity 0-98% (noncondensing), 
alt: 0-7000 ft 
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Plexus P/40 is a 16--bit minicomputer system designed The P/40 UNIX system is idea! for technical or busi- 

specifically to operate-with the popular UNIX - operating ness environments where demanding professionals 
system. The P/40 features a large main memory, high- require a powerful yet easy-to-use computing facility, 

performance peripherals, and built-in error checking A typical P/40 configuration gives 5 to 15 users the 

and correction for faster, more reliable operation. memory and disk capacity they expect to find only on 

Communications processors to offload terminal and the largest minicomputers, but at a cost per user that 

other serial I/O functions enhance system performance is competitive with small microcomputer systems, 
further. In addition, the P/40 features the industry- 
standard Multibus'® I/O bus, allowing users to tailor 
systems to particular applications with a wide variety 
of auxiliary devices. 


Features 

• Multiprocessor architecture links as many as eight 
16-bit microprocessors for high-performance comput¬ 
ing and I/O. 

• Main memory, available in 256 Kbyte and 1 Mbyte 
increments, ranges from 256 Kbytes to 4 Mbytes. 

® Multibus-compatible I/O bus allows ready attachment 
of peripheral controllers for a wide range of specialized 
hardware configurations. 

• Modular intelligent communications processors support 
8 terminals or communications lines per module. Up 

to 3 communications processors can be configured, 
for a total of 24 lines. 

® Intelligent disk controllers support 72 to 580 Mbytes 
of error-correcting Winchester disk storage. 

• Standard S-track magnetic tape drive doubles as a 
high-speed streaming drive for disk backup. 

® The P/40 system supports V7, the Plexus adaptation 
of the UNIX operating system (version 7). 

• P/40 software is compatible across the entire Plexus 
product line. 



The P/40 main processor includes a 16-bit CPU, floating¬ 
point processor, battery-operated clcck/calendar, and 
vectored interrupt controller. 

The CPU (based on the Z8001) has more than 110 
distinct instructions that operate on 7 data types, includ¬ 
ing bits, 32-bit words, and strings. For easy program¬ 
ming, it has 16 general purpose registers and supports 
separate instruction and data spaces. The CPU also 
supports privileged instructions. 

The floating-point processor performs single-precision 
(32-bit) or double-precision (64-bit) addition, sub¬ 
traction, multiplication, and division, it is compatible with 
the IEEE format. 

A battery-operated real-time dock gives the CPU 
continuous access to the actual date and time of day. 

T he clock remains operational even when AC power 
is removed from the system. 

Multilevel interrupt vectoring saves the CPU from 
having to identify each interrupt. Sixteen major interrupt 
levels include I/O transfer complete, memory error, 
interval timer, page fault and privileged instruction violation. 

Burst-multiplexed direct memory access (DMA) is used 
to transfer data between devices and main memory at 
rates up to 3 Mbytes per second. Since each peripheral 
controller has its own DMA, intelligence, and buffer 
storage, the main processor is interrupted only after 
an entire I/O operation has taken place. 
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The system is designed for flexible configuration. All 
boards plug into a 12-slot backplane. With standard 
peripherals, the backplane has 4 slots for memory boards 
and 5 open slots for additional Multibus-compatible 
I/O controllers. 

Efficient Memory Management 

Memory management in the P/40 is optimized ror high per¬ 
formance computing with the UNIX operating system. The 
large amount of memory available for operating processes, 
combined with separate data and instruction spaces, 
give the system attractive throughput characteristics. 

Data transfers between the peripheral controllers and 
main memory take place through the memory manager. 
Transferring data directly into the logical address space 
of any process executing on the main processor signifi¬ 
cantly increases throughput. 

Address translation takes place through high-speed 
bipolar RAMs that form 16 process spaces. Each process 
space contains separate instruction and data maps. 

Each map can contain up to 128 Kbytes of memory ~ 

64 Kbytes of instruction and 64 Kbytes of data. Because 
each instruction map has read-only access, all the 
code generated is sharabie, reentrant code for efficient 
memory use. Also, the large number of process spaces 
reduces the context switching time necessary to run 
multiple processes. 

High-speed memory Is available in increments of 
256 Kbytes (16K dynamic RAMs) or 1 Mbyte (84K dynamic 
RAMs), up to a maximum of 4 Mbytes. Memory is divided 
into pages of 2 Kbytes each. 

Mempty cycle time is 600 nsec. Cycle time includes 
translati 3n of the logical address to the physical address, 
memon access, and error detection and correction. 

Single-bit memory e r ror correction and doubie-bit 
error detection are provided for all accesses to main 
memory. Data is stored in 22-bit words logically organ¬ 
ized as 16 data bits and 6 error correcting bits. 

Up to 16 Kbytes of PROM and 2 Kbytes of static RAM 
are also in the C^U. PROM and static RAM are used for 
seif-test and diagnostic routines. 

Standard Multibus Interface * , 

P/40 architecture provides a high-speed synchronous 
path between the main processor and memory, yet 
makes available to the user the many Multibus-compatible 
controllers available in the marketplace. 
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Plexus P/4G Computer System Block Diagram 


Communications Processor Handles Terminals 

AH serial communication tasks are handled by the Plexus 
Communication Processor (PCP). it contains a 16-bit 
processor, memory, 8 serial ports, 1 parallel port and 
9 DMA channels. Typically, the PCP is programmed to 
provide all buffering and protocol conversion necessary 
to support terminals, modems, and printers. Each full- 
jduplex serial channel supports' asynchronous, bisync, 
lor HDLC protocols at software-selectable rates up to 
19.2 Kbaud. Each channel has its own DMA, so all 8 can 
operate at the maximum baud rate simultaneously. 

The PCP has 32 Kbytes of RAM with parity and up to 
16 Kbytes of PROM. This large memory allows segments 
of UNIX or customized communications and terminal 
handling programs to be downloaded to the PCP and 
executed locally. 

The 8 serial ports are RS-232C compatible and have 
the modem control lines necessary to support standard 
asynchronous and synchronous modems. The parallel 
port is designed to support a line printer with a standard 
(Centronics-compatible) parallel interface. 

Intelligent Disk Controller 

P/40 has an intelligent disk controller that supports up to 
4 industry-standard SMD drives. The controller contains 
a 16-bit processor, 10 Kbytes of local memory, and a DMA 
channel. The controller performs multiple sector transfers 
that span cylinders, automatic error recovery, and trans¬ 
parent error correction for burst errors up to 11 bits long. 

The standard Winchester-type disk is a 14-inch fixed 
disk with either 72 or 145 Mbytes of formatted capacity. 
The drive has a 35 msec average access time and trans¬ 
fers data at 1.01 Mbytes per second. 
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An intelligent 9-track magnetic tape controller supports 
up to 4 industry-standard drives. The horizontally 
mounted unit features automatic threading and can be 
used in two ways. 

In streaming mode, which is used for disk backup, 
the drive stores 46 Mbytes of data in 4.7 minutes on a 
10.5 inch reel of tape, in conventional mode, the ANSi/ 
IBM compatible 1600 bpi drive provides a convenient 
method for exchanging data with other computer systems. 

Built-In Reliability 

P/'40 minimizes the two most common causes of down¬ 
time in small computer systems: memory errors and 
disk drive failure. The P/40 main processor automatically 
detects and corrects memory and disk errors. 

In addition, the state-of-the-art P/40 system, with its 
extensive use of LSI circuitry-and reduced parts count- 
is inherently more reliable than earlier designs. 

P/40 was designed from the outset for ease of service. 
At the time the system is turned on, each processor 
automatically performs a complete self test and displays 
the results on the main processor console and on 
arrays of light-emitting diodes on the boards. The main 
processor has a diagnostic port that connects a terminal 
or modem directly to the main processor. This port can 
be used from a remote location to isolate many hard¬ 
ware and software problems. 

All. P/40 circuit boards are easy to access and 
replace. Mean time to repair is under 30 minutes with 
no special tools. 


P/40 is designed to operate in an office environment. It 
requires no special environmental control or power 
conditioning. The system, including the disk and tape 
drives, is packaged in an enclosure 42 inches high. 


Specifications . 

Size 

Height 

42.0 in. (106.7 cm) 

Width 

23.0 in. (58.4 cm) 
30.0 in. (76.2 cm) 

Depth 

Weight 

295 lb (134 kg) 

Power 

115 vac 60 Hz 

10 amp 

230 vac 50 Hz 

5 amp 

Environmental 



Operating temperature: 5°C-38°.C (41°F-100°F) 
Relative humidity: 20-80% without condensation 


UNIX is a trademark of Bell Laboratories. Plexus Computers, Inc. 
is licensed to distribute UNIX under the authority of Western Electric 
Company. 

Multibus is a trademark of Intel Corporation. 


Plexus Computers 
Incorporated 


3375 Scott Blvd. 

Suite 340 

Santa Clara, Ca 95051 
408 • S88 1755 
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ABSTRACT 

This document reflects our experiences and opinions in configuring 
four existing VAXes and two more that are on order to run TJNIXj* 

Our prime considerations in choosing equipment are: 

• Cost 

> Reliability 

® Maintainability and Maintenance Cost 

• Delivery Time 

• ' Redundancy of the system 

"We consider components individually and then describe several 
system packages built from these components, emphasizing 
independently single-source systems, minimization of cost, and 
maximal expansion capability. 


Copyright © 1961, Bob Kridle and Bill Joy. Copying in whole for per¬ 
sonal use by sites configuring UNIX systems is permitted. Repro¬ 
duction in whole or in part, for other purposes is permitted only 

■with the 'express written consent of the authors. 


' f UNIX is a trademark of BeD Laboratories. _ ' 

•VAX, .VMS, MASSBUS, and UNIBUS are trademarks of Digital Equipment Corporation. 
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DISCLAIMER 

This documents reflects our personal opinions. We are responsible for software 
and hardware support of VAX systems, and the recommendations we give reflect 
Xt we would do We are careful to note the equipment that we recommend but 
are not using; we recommend no second-vendor equipment that is not known to 
be in use successfully at several UNIX sites. In any case you may get a lemon, no 
matter what you buy. All we promise is that this is what we believe. Let us know 
■what you find out. Prices are constantly changing and may be inaccurate. 

We have little familiarity with VMS. Recommendations made 1sere should not be 
construed to be applicable to any operating system other than UNIX. We have 
often adapted UNIX to these devices in a way that may not be possible with ovher 

operating systems. 

Finally note that we have written this document to share the knowledge we have 
acquired with you. We have written it because we do nor have tne urns to talk to 
everyone wfco needs this information. Flease do not call us to confirm the irfor- 
mai'on here or to ask questions about our opimons. We would like to hear of 
your experiences, or learn of mistakes in this document or P/oducts that we 
Low nothing about, but do not have time to chat about the mfo ™^io" that is 
given here. We do welcome electronic mail sent to our addresses as shown on 

the first page. 


OVERVIEW 

We first discuss components, listing the alternatives we have tried and some- 
toes a few we haven't and then discuss system packages. V*-big-a ^anUa 1 
portion of the equipment we use from vendors other than D ,C. The 
choosing second vendor equipment are usually some combination of more 
current technology, lower cost for equivalent equipment or shorter cell ery 
-Ivroe. 

We do not consider devices that have proven unreliable or whose‘ 
we consider inadequate. In addition, there are many devices that we have no 
experience with. As a general rule, every new peripheral has required an 
trivial amount of leg work to get up to speed. We suggest using only peripherals 
that have been previously used successfully on thf t'ype of VAX you are 
configuring (780 or 750) or demanding a substantial (aO-100 percent) discount 
forSTa guinea pig. Be especially careful of UNiBUSf interfaces. Almost 
every manufacturer o?a UNIBUS widget now includes, the VAX as a machine on 
which his device will work. Few of these devices have been tested a tins si.ua 
tion. Many of them will not work without substantial modification. 

All prices quoted are undiscounted, quantity one unless stated to be othermse 
and are accurate to the best of our Knowledge at this wmmg 
at least an educational discount and sometimes a cuanuty discount The yp 
cally reduce the list Drlces from ten to forty percent. Since discounts var y - 
erea to area and prices change frequently, you should always request quotations 

from local vendors. 

System buyers without ready access to an in-house hardware staff should Gan¬ 
ger carefully the option of buying as much TEC equipment as possife . > 

have the money and time required to do this, there are some strong advantage^ 
Our DEC equipment has, in general, proven somewhat moie relm £ to 
equivalent alternate vendor equipment. Time from equipm *7 
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running system is also usually shorter. DEC field service in our area is excellent. 
Outside service available for non-DEC peripherals is spotty at best. 

For smaller installations this option should be carefully considered. It is easier 
if vou can call one party for all your problems,-ir you can afford it At Be. 
we are-well past the inventory level where self maintenancei begms to paymff 
even on all DEC systems, so this is not a consideration. One of Uo (Xr*a.e) 
manages our local hardware support group. 

Unfortunately, the limited selection of configurations currently available.some¬ 
times make the all-DEC choice difficult This is especially true £ the-maw 
configurations as DEC’S bottom end peripherals are .ess satisfactory for hi .IX. 
We sav this not just for monetary reasons; functionally and aesthetic^!/ 
woull prefer to hive neither the RK07 disk nor the TS11 tape unit in any system 
we have to deal with. _ 

We recommend getting field service at least on your CPU for the toyear, w 
has paid off for us in the cost of parts alone. You can drop the coua.. aft 
the engineering changes have tapered oil and most of the ini ant taUures 
occurred. DEC requires a certain amount of its peripheral ..equipment on the 

machine to qualify for field service. We understand that 11 w L^PC ma ss° S 
to provide a maintenance contract for a system without a DLCmlaa 
peripheral. If vou intend to purchase a maintenance contract, be certain uhat 
your local fiekTservice is willing to support at least the DEC equipment >ou ou>. 


BANDWIDTH CONSIDERATIONS 

Evaluation of the data transfer capacities between the various parts of VJU sys¬ 
tems is a. complex task that plays a critical part in system, configurahon. 
funatelv there is a'tremendous amount of misinformation avcmaole on this ..ub- 
ject and little useful hard data. We have made a few measurements and m.snd 
to make more. What we currently know follows. 

The 11/780 UNIBUS adapter is the device most frequently shrouded in confusion. 
DEC documents variously give the bandwidth at between 1.2 l.B/sec and l.u 
^sec Xn transferring through a buffered data path. We are not aware or 
any specifications for the unbuffered data path but have not been aole to use r 
■with some devices as slow as 50 KB/sec. One experiment we conducted involved 
examining the UNiBUS protocol lines with a scope while constantly transferring 
from a disk drive. We observed that while the drive was trans.ern.rig a. ar. av .r- 
aae rate of about 1.2 MB/sec the UNIBUS was close to one hundred preeent 
busy This test was conducted on an otherwise idle system. No o.ner 
were acUve on the UNIBUS and large disk transfers (cylinders) reduced my 
register set up time to a minimum, ffe conclude irom this am I' 
tbe absolute irjzximwm transfer rate possible Uirougu a l./i8 . i - t.fi*' 1 ?. j" 

Our observations showed that the largest delays while transterrmg 
occurred while the buffered data path was being loadea or umoad^d fr m 
SBI. Since the UBA is controlled by a micro sequencer that is -iso' u^o!.ved ” 
other UBA activities such as processing interrupts, we suspect Jut on an acuve 
UBA this bandwidth may be somewhat reduced. 

It is also our conclusion that UBA bandwidth is not an important limitation m 
most applications. Most modern disk controllers nave, ar .east IboB byte, or 
three sectors of internal buffering. This means two things, first, .„<.y era be 
■^esioned to never produce data lais error conditions regard.ess of the t.m.f-r 
size® deco^rthey can complete an entire track transfer without losing a 
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revolution in all but the most adverse circumstances. UNIX rarely makes single 
transfers larger than a single disk track. ^ 

There are troublesome devices that cannot buffer enough data to guarantee that 
Se marimum s ze record can always be transferred (6250bpi tape dfive*) or do 
not adequate amount of data {RK07 disk controller). To handle these 

devices UNIX provides a software interlock mechanism that prevents excess 

contention. , 9J . 

The MASSBUS adapters are specified to have a higher potential^bandwidth o . 
MB/sec. Since they are selector channels that allow only one oevice to trans er 
data at a time, the realized bandwidth Is limited to the rate of the fastest device. 
The & fast^st^devices currently available from DEC for 11/^.^?™.^ 
systems with a single memory controller transier a. 1.3 MB/sec. La ^S / 
svstems with two memory controllers and interleaved memory may run HP07 
disk drives that then transfer data at 2.2 MB/sec.* 

We have measured the average throughput of disks with a maximum transfer 
rate of 1 2 MB/sec (RMC^ equivalent) using three different interfaces on an idle 
11/780 system The interfaces included a DEC MASSBUS adapter, a foreign ven- 
dor SBl inteXce and a foreign vendor UNIBUS interface. In all three ,the 
throughput was within a few percent of the maximum rate for the disk drive. 

Our conclusion is that for most UNIX applications. ^ ™ 1 ? U f j^® s " 

quate. It is usually equivalent in performance to ^ SSB ^f B { J n s l " r t aC rf^ c ? ' has 
and less “xoensive. The long history of foreign vendor UNiBUS interfacing na_ 

created a rich and competitive market of devices. If "^TsIbUS adapter 
UN3BUS adapter can be added at a cost similar to that of a MASS p 

mid is fully supported by UNIX. 

A more interesting bandwidth limit may be established by the memory com 
troTler We suspeS that the. CPU may be slowed considerably ]° d Z 
ipntion when two disk channels are being used simultaneously. This suoola ~e 
Xrted by Sng interleaved memory controllers. We have a second memory 
controller, not yet instated, and intend to attempt measurements sooa 
The appendix to the VAX Hardware Handbook «t!ed “System "^“^Put 
' siderations" seems to bear out these impressions and sh< 5 uid be reaa «i. .y 
bv anyone honing to understand the consequences for \AX applications involvi g 
hieh bandwidth input or output. If we had data intensive applications we would 
seriously consideAhe use of RP07 disks (and interleaved memory controllers) 
because of tte resultant higher burst transfer rate; this mil be discussed 

further below. 


• On machines rtfh only one memory controller the EP07 hardware is arranged totranter ■at 
1.3 h™seT:t is our Znderetandir?that HP0T. trill work on ling, with a smgle memory 
controller at 2.2 K3/sec. but R?07s are not currently sold for 11/ i503. 
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MEMORY 

All VAYM are sold with some minimum amount of DEC memory adequate to run 
“alnosUc^ Adlw memory is the lowest risk alternate ^«ce We 

buy the remainder of our 780 memory from arek is 

data.”” We are currendy-paying abo a . £,0U> *;; w * nd £ s . By all means, 
extremely competitive and triers are aw least o po^iui- fwt 

ask for competitive quotes. Assure yoursei*. nowevw., cuat. ^ 

customer for a new vendor. 

, ,. . mpmnrv for the VAX 750 is a nfrwer item and prices are no- as low. now- 
tver tWs memory S it identical to the U/70 MK11 memory ami several 
vendors have managed to build this product by modifying *eu previous ., ^ 
add-in product. Trendata 750 memory is currently listing 
Kbyte board. A fifteen percent educational discount is avails • 

GSA discount is also available. 

Small quantities (one to two megabytes) are usually mailable oStne 
Trendata or National, Large quantities (4 megabytes and up) n* 

than 30 deys. - . . r 

For the 11/780 memory, the RAM chips are socketed, and two replacement chips 
per bcfard are^ supplied by both Trendata and National; these are rhe on* two 
second vendors whose memory we are currently .usmg. .ou‘ oorreo ^ 

board and replace the chip at your leisure. hinc~ single “ / ' t , t a one 

?w?hJ?n*>vJr involved any unexpected down time lor us. There is at least a one 

yewr return to factory agreement on the boards, inci.uciedtne purcuase^priue^ 
Out of warranty repairs are said to typically cost jess than *oUL. 
returned only one board to the plant in, about 30 board years. 

Vilien purchased from DEC. memory is $19,800 per 

?ZZ^T^ZZ y Tafbo^, socketed. Delivery times on memory 

rom DEC have typically been substantially longer than times rom secon 


K vou gj-e going to have more, than 4 megabytes of memory to y° ur ^ 

lfyou are g * cabinet at $4,480 and a second memory coni, u.ler for 

need-a CPU expansion caoiuu « *>**• f memory it is not 

$25,600 that includes a second ba*£-me B aDyte of - - ThbPreflects both 
additional controller. 


There are three alternatives for disks. The first is to buy the disk u^dwarc. from 
TOO The available equipment includes 67M byte removable mOc* jf-M 

brte Movable disks (K, 105) and 124M byte non-removabie vBMBO). and a 

new an? aggressively pric'd 504M byte non-removable disic <RP07> that can be 
Sat ™ at 2.2 M/sec on 11/780’. with interleaved memory.” 

«AE*t of s«con3 vendors end pr wertsffiie mwetdSl’hTSHega- • 

f ¥e have heard that a recem UbC held change order pr-%exi-o 

^ytes of memory on an 1 . ^ - r . a ^ w •** of formatted space available. 

* Disk sizes shown throughout this document mv ns, 071 - 
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DEC also sells RK07 cartridge disks that we don't consider a viable option for 
UNIX for several reasons. They will not work concurrently with other UNIBUS 
DMA devices because of insufficient buffering (we mitigate this somewhat 
through software interlocking on the UNIBUS) and they are small and slow. If 
you get a system with these in it you can sell a drive and keep the other to have 
a DEC mass storage peripheral for maintenance reasons. It is currently possible 
to get roughly $7,5Q0 for a single RK07. 

The viable DEC disks run on MASSBUS adapters, and are, except for the EM BO, 
other manufacturers' drive hardware with some DEC electronics added.. The 
DEC disks are significantly more expensive than the alternatives from other ven¬ 
dors, The second-vendor UNIBUS controllers use. bit-slice technology and micro¬ 
code, while most of the older DEC controllers use discrete logic. The following 
summarizes the .cost of the drives available from DEC including tv>o packs for 
each drive where applicable; sizes shown are formatted space available. First 
drive prices include a MASSBUS adapter. 


Type 

Size 

First 

Maffit 

Add-on 

Maint 

RM03 

67MB 

$30,935 

$179 

$20,935 

$147 

RM05 

258MB 

$45,450 

$310 

$35,450 

$240 

RMB0 

124MB 

$29,900 

$132 

$19,900 

$100 

RP07 

504MB 

$48,000 

$240 

$38,000 

$180 


The second alternative is to get a MASSBUSf look-alike. Systems Industiies will 
sell you a modified 9400 controller and storage module CD.C 258MB removable 
pack drives or Fujitsu 134MB Winchesters. These setups are less expensive than 
the same capacity from DEC. but are currently available only for 11/780‘s as far 
as we know. We currently do not use this equipment at Berkeley but are aware 
of several satisfied users running UNIX. For disk I/O intensive systems, having 
the extra disk channels offered by MASSBUS adapters or multiple UNIBUS 
adapters is a definite advantage. Costs from Systems Industries including two 
packs per removable media drive are: 

Type Size First Main! Add-on Maint 

CDC 9766 256M 138,506™”$225 $19,400 ”$466 , 

Fujitsu? 134M $22,000 $173 $9,500 $114 

CDC 9775 578M $39,900 $226 $28,500 $167 

The final alternative, and the one that we prefer for all but the largest 11/780 
systems, is to get a. UNIBUS storage module disk controller and some storage 
module drives. We run most of our disks on the UNIBUS, and have had good luck 
doing so. Each of cur VAXes has an Emuiex SC21/V controller with one or more 
Ampex 9300-CD 253MB drives. The Emuiex controller is a single card in the 

♦ DECconsiders'at lee.st some MASSBUS emulating Interfaces to infringe on their hardware 
patents and axe purs 1 ling legal action against selected vendors. We are not clear about the 
implications of this for users of these devices. 

© if j 0U pijt Fujitsu drives on a Systems Industries controller, the drives normally appear to 
be multiple RH03*s xo the system. This causes problems in that the system thinks it can do 
parallel seeks on d ives that actually are pieces of the same drive. Some rites have modified 
the drivers to alleviate this problem, but these modifications are not part of the standard 
system. There is also an option to cause the Fujitsu’s to appear as single large drives, but 
tlx© drive type register still says that the drive is an RM03. We are t&Ikang to SI about maxing 
St possible to discriminate the devices in the software, but this is not yet in the standard 
release. 


88 


AUUGN 




Components 


-7 


© rwk/wnj May, 1981 


UNIBUS tux a.m handles up to 4 storage module drives. We get a betterpnce 
from Ampex than from CDC, whose 856MB drives seem about equivalent Erarne^ 
and CDC have an agreement for service through uDC organizaaons ■ ^ 

CDC drives'. We maintain our Ampex drives m nouse. The .... ' ' 

for $6,000. Quantity one list price for the Ampex 6300 -Cj) is ^14.000 C^ble^ run 
about per drive. We buy Dysan error free bOOMB packs for about vl.vJO 

SchM for each drive). Thus the total cost for a 853MB drive and its packs is 
$22 250 . Kon discounted CDC prices add about $2,000. Below we show package 

prices including cables and 2 packs. . » , _ n 

Another good storage module drive that is running on Vte ^/cbestlr^ri^ 
Laboratories with the SC-21V controller a the iujitau 104M 3 nebesi 
We have had extremely good reports on this drive, althougn we doa have an. 
ourselves. The Emulex .storage module packages we suggest a*e ‘-bus. 


Type 

Size 

First 

Maint 

Add-on 

Maint 

Fujitsu 

Ampex 

CDC 

134MB ’ 

253MB 

256MB 

$13,750 

$22,250 

$24,250 

??? 

t y 

1300 

7,730 

$16,000 

$18,000 

??? 

??? 

1224 


We use Emulex TC-U/P UNIBUS tape controllers that list.for...“ d " 2 ; ir - J 

model 9300-3 800/1600 BP1 125 IPS transports at $7.*00. t oo 

to mount th- tape drive and cables. An assembled system Usu> .or abt. ui 

tSS KAX-m * . Th, Kennedy «-—«---» •» 

card swaps cost about $75. For transport mechanical failures the transpor is 
returned to the factory in Monrovia, California, or we Ox it ourseives. 

„ r ,, Wp pY perdue is usinp a 6250 tape system, with UNIX. It includes a 
T*l°/x 8*53drite (800/1600/6250 BPI) 125 IPS with a TELEX Formatter and an 
Telex 6^5d ' T i uq i«t Pr f a ce The UNIBUS interface has 4KB of buttering, to 

^ with bus 0° 


system costs him about tf«.uuu. jx enuaa^ * irnh itotbUS access 

WP 7 /PF mntroller 6^50 at 125 IPS and uses the entire UbA. UNIBUb access 
JNR2j/rb controller. _ «en PPl i»r>e drive and a 

bv the ©Derating system to ctllow a owoU ari u*p- unvc c 
can be arbitrated d/ui« ^ ?#• nnnecearv N B • The driver for this 

*. *. in poeyist on one uBA if necessary. n.n.. *>***«- „ 

conlroiler/lransport combination is not currently included in the stan ar 
4. ibsd system. 


Kennedy 

Teles 


Speed Densities 


■lpS 


800/1600 
BOO/1600/6250 


$12,000 

t;DO 


*** 3,000 


Maint 


(No driver in 4. 


Our original VAX system came to a package with a DEC TE18 on its own MBA. The 
wifi kt-liable but slow. The DEC 7U45 is faster, but traugttt with problems a. 

Tulb i«s rename tr.. ThT , c *ss *» nn-iH tirs^nsrjf'irt* hut ci.e 

the hi oh maintenance cost reflects. The DEC ru7f us a good tranAp-n., jui 

auto-Ladimi features don’t seem to work well, and it is expensive, r irmly, t -.ft. 
auto loaum^ . -nvr . isno/RPSOboi 185ips tape drive, tne Tu78. Tin. is 

iss 8, new product f.i um B—iC, t. - / ^ , ,3 *.;%*«¥* f nr , in the current 

the same transport as the TU77. We do not have a a "ver ror 6 250boi tap^ are 
distribution. (4.ibsd), but expect to have one soon. As btodbpi t P 
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desirable in systems with large amounts of disk storage, we expect that this^will. 
be an attractive tape drive to include in systems .with large amounts of disk 

storage. , . ■ 

The UNIBUS tape, the TS11. is included in packages for the 11/750 except for 
the RK07 package system. It does not have a vacuum column, and is tnus hard 
on tapes. It is a problem to load and seems to be unreliable. 


Name 

Speed 

Densities 

Cost 

TS11 

45ips 

1600 

$13,396 

TE16 

45ips 

800/1600 

$22,000 

TU45 

75ips 

800/1600 

$25,424 

TU77 

125ips 

800/1600 

$30,453 

TU7B 

125ips 

1600/6250 

$52,000 


Mtce 


$75 

$147 

$285 

$235 

$340 


(Not recommended) 
(Not recommended) 
(No driver in 4.1bsd) 


terminal interfaces 

With a VAX you get 8 lines of DZ-11 that provide some modem control but are not 
DMA. We use the Able DH-11 emulator, the DMAX/IS, that gives 16 lines of DMA 
output ports without modem control for $4,500, or with modem control for 
$5 300 We have been getting about 30 day delivery on the these. We are 
currently testing new products from both Able and Emulex that have lower costs 
per port and consume less backplane space and power. We expect to finish 
evaluating these units soon. The current alternative from DEC is more D^-11 s, 
that cost $2,050 for 8 additional lines, that can be accommodated m the same 
distribution panel, then $4,300 for each additional 16 lines. 

Both the BZ's and the DH’s have input silo’s that UNIX can use to reduce inter¬ 
rupt load on input. The DMA output of the DM AX is especially important lor 
graphics applications where high-volume and continuous output occurs. 


MODEMS 

We buy Vadic modem racks for the system end. Vadic oSers modems that can 
talk both standard 300 baud and also the two commonly used 1200 baud styles. 
Bell 212 and Vadic. It is handy to have these "triple" or ^-way modems in 
your machine. 

Here are the list prices of various components. 


Chassis $450 

Power Supplies $200 
3-way Answer $850 
Autodialer $500 

RS232 to RS468 $500 

300 Orig/Ans $450 
1200 Orig/Ans $740 


(Provides 18 slots) 

(You can use two for redundancy) 

(Takes 2 slots) , , . 

(Takes 1 slots, and need 300 and/or 1200 slug belOTj 
(Converter for autodialer) 

(Takes 1 slot, for autodialer) 

(Takes 1 slots, for autodialer) 


A rack with 5 3-ways and no auto-dialers would cost about $5,100 and would hav * 
6 free slots for additional modems. A rack containing 5 3-way modems, an a 
300 baud and 1200 baud dialer would thus have only one free slot, and would cost 
about $7,250. This equipment has had some infant failure problems. 
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The Vadic home-end originate answer 300/1200 modems that can also ta.k to 
Bell 212 modems are $750 when purchased with Voice/Data switches, inese plug 
directs into modular phones. We have had trouble min initial reuability on 
these; '"about 1/3 don’t work when received.. We are curremiy uy^ erne, 
modems for home use and reliability seems unproved i hey too -re 
These are only two way, 212 std. for 1200 baud and 103 scd. mr oQO baud out 
since we have no vadic only answer moderns, this is not a problem for us. 

We have heard of a new BEC product in modems: the BF03 It is a 300/1200 baud 
modem using a chip to do the Bell 212 1200 baud standard. It ££ 
priced, the DF03-AA is $950 and a unit that prowaes a^-calhng. toe 3F03 At * 
$1,350. These have been .used successfully by the UNIX group at. L^C fcr -om, 
months now. We are hoping to try some of these soon. 


TE. 


We have been using some Printronix 300 tine per minute dot-matrix printers. 
TOeyl to poTnt-pIotUng at 60 point, per inch, They are not outstandingly oneap 
($ 7 , 000 ), but are ruggedly built 

The new Bata Products B-6Q0-1 is a 800LPM berndjrinter^ms sells for | r.500 
with controller. Although we don’t have one of these, Tom Terim at uU>i 
been using one for four months and is satisfied. 

PLOTTERS 

Electrostatic pririter/plotters that are capable of 200 dots/inch are ^bleboth 
as orinters and as output devices for trojf. Vie have an old niodel \ arian th 
reauire 1 * considerable care and feeding; newer models are said to be less of a 
headache' 4 new Versatec 11 s * model sells for about $6,000. The objections to 
th^ puys are that the paper tends to be wet sometimes, simky t and more 
e^iivfthTn line printer (S20 per 1000 sheets). These are Ingh ms^enance 
items es are all heavily used hardcopy output deuces we are faiiuUa, with. 


We are currently getting experience with an Ungermann/Bass WET/ONE local 
network interface, which uses an hthernet-tecnnology na-or.. -t - 

raicn rpfb'-n? « c me BMR-il interfaces from DEC, that auuv. poinu-v,o uom*. n..t 
worki/at up to IMbit/seo. The older DMC-11 interfaces can be made to work at 
high speeds only by modifying the hardware and should probably be avo*a_d. ^ 

y?e, arp hnn°nt' learn much more about local network products in use next few 

£ hear any W user experience with different commer- 

dally available, devices* 

• Srteodde^ »« aew taer have y 

A „Ace% now commercially avaHaele: one irom Canon asts *Oi ac-au* 

Lmea Tri^/either BS232 or DR-H interfaces, and another we have heard of nst* for about 
$8,000 in amall Quantities; look in recant DATAMATION issues sor detedt*. 
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We now present some sample system packages. Each represents a balanced sys¬ 
tem for timesharing use under UNIX People often ask us how many users can 
be supported under UNIX in these configurations. In the absence of specific 
information about applications to be run this is an unanswerable question The 
amount of load, presented to the system by different applications varies widely. 
We mention with each system the count of interactive users typical of our 
university research environment that could be supported by the system. 

We first present systems based on ll/750s and then systems based on ll/780s. 
With each system we suggest similarly functional systems configured m at leas 
two different ways: first with as much equipment as possible from DLL, and 
second with the best equipment known to us. 

Various people have measured the speed of 11/750’s and 11/780’s and found 
that the 11/750 executes at roughly 60 percent of the speed m an 11/780. By 
comparison, an 11/70 runs at roughly 75 percent of the speed o. an 11/780 on 
the same benchmarks, that involve no floating point, no 32 bn curithmetic on the 
11/70 and also no system calls. For time sharing UNIX usage we believe that the 
•Xl/750 should have better performance than an 11/70. ihe additional tuning 
end performance enhancements to the VAX kernel and larger address space of 
the VAX provide the boost for the 11/750. 

The first system we consider is a small 11/750. We are fond of the 11/750, as it 
is cost effective for small systems. The problems -with startmg with an ll/7bb 
ere that it is not as expandable as the 11/780, and that there is currently no 
hardware floating point unit for the machine. We present an expansion of Jie 
11/750 into a larger system. 

The second base system is a small 11/780. We show how it can oe bmlt from a 
DEC RM80/TU77 package system, and two different ways to build u from a .un 
RKQ7 package using the best equipment that we are aware of, emphasizing 
either lowest cost or capacity for expansion to a system with high i/ o bandwidtn. 

The small systems we suggest start with a single disk and tape controller and 
some memory. For time-sharing applications we configure our VAX systems 
allowing 258k bytes of memory for the kernel and rougbiy an additional llOk 
bytes cf memory per active user.® Memory is cheap, especially for the 11//B0 8 
so we don’t skimp on it. 

With more than a few users, it is critical that more than one disk arm be present 
in the system. Thus all but the smallest systems include more than one disk. As 
the active user count rises, having more than one disk controller is also a good 
idea. Tie large system packages include more thar one disk■ 
large and i/o intensive systems we recommend the fast new Ri 07 drive from 
DEC as it runs at 2.2 MB/sec, twice as fast in burst rate as the other drives; this 
requires running with interleaved memory. 

It is desirable on all UNIX systems to have at least 100MB of disk space so that 
all the source for the system and all the standard programs may be kept on line 
with some room for locally developed programs. The amount oi space required 
by user programs varies per installation; we manage to run many o our 
instructional/research, machines using about 300 megabytes of space actively, 
although slightly more than this would be desirable. 

« These numbers work reasonably well in an environment typical of Unijeraity work (course 
work, paper preparation, debugging programs, developing applications for microcomputers, 
etc.) More demanding applications could require substantially more memory per user. 
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Our large research machine runs with 1 Gigabyte of disk storage, with 2 disks on 
a UNIBUS and 2 disks on MASSBUS adapters. The-weakest point m tms ^y^tsm is 
that it has only a 45ips TE16 tape drive for backups. Tor even the s-malles^sys¬ 
tems, *45Ids will soon seem slowf We therefore recommend st^ti^wlha^l^ips 
ISOObpi tape drive. As full 2400 foot tape reels hold only 30MB at ioOobpi, large 
systems would be a good idea to include a 8250bpi tape drive. 

Finally, in all but the smallest systems we include modems printers. 300 
baud modems are painfully slow, so all our systems include 300/...00 modem-. 
Given an auto-call unit you can hook your machine into a ioosely coupicd ne 
work of UNIX machines called the uucp network. As such autu-cai. uct-. - 

inexpensive, adding one can be a valuable way of tying into the UNIX &om...un.ty. 


Ve want to put together a small 11/750 system capable of supporting about 8 
time-sharing UNIX users, and a larger 11/750 system for rough / lb-24 useis. 
¥e need a minimum of 100 megabytes of space for the small system Mid a rea¬ 
sonable tape drive, preferably a 125ips drive so that tape operationsi canb- 
done in a reasonable amount of time; if the system is to incluc; om>'non¬ 
removable disks, we consider the faster tape system to be important, .u th~ 
larger system, we wish to add disk space to give the system a minimum oi <.-0 
megabytes of space, and. have more than one disk arm. 

When buying an li/?5.0 the most difficult problem Is the sales packaging of the 
systems. DEC currently packages only 3 11/750 systems, tua « are not^oapK 
wth the tape equipment in any of these systems, fhe mic.l Lnu uy*tem 
includes 2 RKQ7 disk systems. These are not adequate tr support our aesiret 
configuration, since they, supply only 28 megabytes o* space each. T • ^ 
system from ali-DEC equipment we would thus svart vnth ine the 
configuration, SV-BXWAA-AA; this lists currently tor 5120,000, lass bb.OOQ 
VAX/VMS license only. The TSU tape drive ls a 45ips ISOObpi only tension mra 
taoe drive, and does not meet all the requirements for uur sys.em. out is .he 
only tape drive available from DEC for the 11/750. We wornd prefer to have a 
125ips tape transport but the only iSoips transports avadaPie from ^ ' 7^ 

too expensive to be reasonably included in this system, even d DEC s- • E 
aging rules would let you buy them. 

You can consider building a system using equipment 

DEC You can buy tbs cheapest currently availaole packagea cunugat aLon. *i 
SV-BXHHA-AA dual RKQ7 system; this lists for $89,900 less ^5,000 tor dropping. 


«. f’-Hann irNDf u^ers ® This'Package represents n*e 

support, or fc8* t 900 list tor mok ujma u ^ 

most cost effective way for .non-OEMs to currently purchase a ’ELiw. ^ 

HKOT’s are not useful A single RK07 drive is required for DEC field se* vice. 

second drive lists for 112,000, and if you can sell it'for 57,500, you can omig *-n 

foundation cost down to about $7? s 


• g yGVi qualify as an OEM, you may 'be able to Vay a W-e CPU for about ^<-9,000 list from 
DEcf we have not teen able to buy the naked CPU eves given the quantity o* hardware we 
'buy from. DEC. 
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To this we would then add: 

0.5M Trendata memory 
Emulex SC-2lV/Fujitsu 
Emulex TC-IIP/Kennedy 9300 


1 MB total 
134 MB 
125 ips 


$4,600 

$13,750 

$12,000 


Total starting from DEC RK07 package 


$107,750 


Thus, summarizing the possibilities, we can start by buying an RM8Q/TS11 sys¬ 
tem; this will give us 124M bytes of disk space and a 45ips tension arm drive for 
$115,000 list price or we can buy. a RK07 system, sell a RKOTjirive, and add a 
Emulex disk controller and a 134M bytes Fujitsu drive and an Emulex tape con¬ 
troller and a 125ips Kennedy tape drive, to a total cost of $107,750. 

Medium system. 

To expand this basic system to support more users and get additional, disk 
space, we would add additional lines, disk storage, modems and memory. To add 
this equipment to the small ail-DEC system we would and another HM80, anothsi 
Megabyte of memory and a DZ-11E: 


RM60/TS11 base system 

MS750-AC IMB memory 

RM80-AA 124MB disk 

DZ11-E 16 lines 

Vadic Modems 

Data products B-SGQ-A 

2MB total 

26BMB total 

24 total 

5 300/1200 
6001pm 

$115,000 

$19,800 

$19,900 

$4,300 

$5,100 

$7,500 

All-DEC Medium 11/750 cost 


$171^00" 

To make this system from the F.K-07 package using non-DEC equipment we would 
add the following equipment to the small system: 

RK0? base system 

1M Trendata memory 

1 134M Fujitsu disk drive 

Able DMAX 

Vadic Modems 

Data products B-000-1 

24 lines total 

5 300/1200 
6001pm 

$107,750 

$9,200 

$7,750 

$4,500 

$5,100 

$7,500 

Add-on cost 

Total starting from DEC RK07 package 


$33,700 

$141,450 


The differences in tbe hardware functionality between the two medium 11/750 
systems are: The BMAX is a DMA device more suitable for high-speed output, 
while the DZ11 is interrupt per character. The system not all from DEC includes 
s. 125ips vacuum tape drive while the DEC system includes a 45ips tension arm 
drive. The all-DEC system has a MASSBUS disk drive, on a diSerent bus than the 
tape. The non-DEC system includes a single RK07. 
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VAX 11/780 PACKAGES 


For a system with more growth possibilities than.ax, H^/. 

(especially floatingj^pomt). ^^ l/ s °A ydth a system capable of support- 

Sg B-tsT^esh^ni use^f td expanding the system to be capable of support- 

tag roU 24 users.%'e also consider a a^tatae 

tem that might support 32 to 40 terminal users to tne exna 

CPU cycles.* 

,».««. ». ^ m £“ Su 

ISOObpi tape toe tbit lhl J at ...tern, » to «M 
eventually expanded. In our first xp ,. _p a\ s ' k storage, acquire at 

to the available space to einto- °J ^0 modem 

least two disk arms, and add a 1 _ . n f ihis system we include more 

equipment for dial-in lines, -n ex ^ ■ t least t. wo separate disk chan- 

^ a minimum of 750 Mega- 

KM80/TU? ( bctsed sys-em, tne o ^ sk drive and a 125ips tape. The 

lines, 1 Megabyte of memory, a 1*4 Mega yt „ eUing a system without 

system Usts for $225,000, and we nan save *5,000 by^ettmg To this 

VAX/VMS support making the basic aU-DEL. sys P e 13 SQ o and a floating 

we would add .5 Megabyte of memory, the Mo7B ® ^ f t $244,500. 

point accelerator for $10,600 to bring the total all-D^C system p>i » 

L we did for the 11/750. we use an®D7 stem ^^mV-CK 

system built using second-vendor equipment. We start 
package consisting of: 

11/780 CPU 
512K memory 
8 lines of DZ-il 
1A1S0 console 

2 RK07 Bisks; and UKIBUS Controller 

VAX/VMS license only _ 

? & * na nnn "We* would immediately sell a HK07 drive- ^ e ge 

This system lists for ^138,000. H - accelerator we get a list price for 

506 for this drive and add a floating pom 

the equipment from. DEC of $141,100. 


dent programming some sites have reports running up 
sre the critical resource with this many users. 
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To form a system with the performance we desire, while minimizing the cost, we 
make the following package: 


RK07 base system 
1M memory 

Emulex SC-2lV/Fujitsu 134MB 
Emulex TC-llP/Kennedy 9300 

Add-on cost 

Total starting from DEC EKQ7 paekag! 


1.5MB total 
172MB total 
125ips 


✓ $141,100 
$5,000 
$13,750 
$ 12,000 


$32,750 

$173,850 


The list price difference between these two systems is $55,250; much of the addi¬ 
tional cost in the all-DEC system is in the two MASS BUS adapters for die RM80 
and the TU77. The bandwidth, of these adapters is not critical in inis small sys¬ 
tem. Also, the TU77 is an autoloading tape drive, while the Kennedy 9300 is not. 
We do not consider these differences significant 

To form a systerii with the emphasis on handling of date-intensive,applications, 
and to emphasize total growth of the system, we would add an KEP07-AA 504MB 
disk drive* and MAS SB US controller to the basic system instead of adding toe 
Emulex SC-2IV and Fujitsu drive. To do this, however, we must expand the phy¬ 
sical packaging, bf the cpu package that we based the system on. 

We want to add another MASSBUS adapter that there is no space in the CPU 
cabinet for. There are two possible ways to solve this problem, me first is to 
rearrange /upgrade the CPU by removing the built in UK IB US backplane and 
adding an extender cabinet buying the component parts individually. The 
second involves purchasing these same ’parts in an -Upgrade Xd from DEC. _ This 
Mt and Its -component parts, as we are aware of them, are described below: 


DEC Pert No. 

■H9602-DF 
BA11-KE 
DD11-DX 


Components Total 
H9604-BA 

Unaccounted for Cost 


Description 

UNIBUS Expunder Cab. 

UNIBUS Expansion Mounting Box 
9 Slot UNIBUS Backplane 
Misc. Cables 


DEC Upgrade Kit 


DEC list 

$3,360 

$3,400 

$900 

-$500 

$8A60~ 

$25,000 

$16340 


phone calls to DEC have not produced any explanation of the unaccounted 

_,46.840 or any reason that you should not simply buy the component parts. 

On the other hand, our sales representative will net guarantee that a system 
configured with separately purchased parts will-work. Our reiuctant sonclusi.cn 
is that . toe missing $16.84-0 is part of DEC’S marketing^ strategy aimed at 
discouraging building up large systems from an inexpensive base. 

We are planning to build two systems this summer using toe component parts 
hereafter referred to as the Berkeley Upgrade Mi, Since we have not yec done 
this and cannot giixirasiies they will work, you. should add tne $ lb. 840 cost to 
these parts to be most conservative about the system package we are,suggest”* 


Thus to form a small system emphasizing expansion we add: 
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RK07 base system 
Berkeley upgrade kit 
1M memory 
DEC REPQ7-AA 

Emulex TC-llP/Kennedy 9300 
Add-oncost 

Total starting from DEC RK07 package 


1.5MB total 
504MB total 
125ips 


1141,100 

$8,180 

$5,000 

$46,000 

$ 12,000 

$73060” 

$214,260 


basic system, to support more users and get additional disk 

space” we would add additional lines, disk storage, ^ od ?^ ^^^^sTalother 
this equipment to the small all-DEC system we would add .mother RMS0, another 

Megabyte of memory and a BZ-llE: 


RMBQ/TU7? base system 
MS780-DC 1 Megabyte memory 
RM80-AA 124 Megabyte disk 
DZ11-E 16 lines 
Vadic Modems * 

Data products B-600-1 

All-DEC Medium 11/780 cost 


2.5MB toted 
•248MB total 
24 lines total 
5 300/1200 
8001pm 


$244,500 
$19,800 
$19,900 
$4,300 
$5,100 
• $7,500 


$301,100 


To make this system from the package using inexpensive non-DEC equipment ire 
would add the following equipment to that small system. 


RKG7 derived base system 

1M memory 

Fujitsu 134MB disk 

Able DPI/DM 

Vadic Moderns 

Data products B-800-1 

Inexpensive medium 11/780 


2.5MB total 
296MB total 
24 lines total 
5 300/1200 


$173,850 

$5.0QQ 

$7,750 

14,500 

$5,100 

$7,500 

$203?70CF 


The differences in the hardware functionality between the two systems . 

1) The DH/DM is a DMA device more suitable for high-speed output, while the 
DZ11 is interrupt per character. 

2 ) The tape drive in the all-DEC system is autoloading. ■ 

»< - DEC system has MASSBUS disks and tapes, while the non-DEC system 

*> ^ Ss peripherSr We do not consider this to be a serious problem 

for a system of the size considered nere. 
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qgwss sssstss ca p -~“ ^ 

ing the following breakdown: 


RK07 derived base system 

1M memory 

RP07-AA 504 MB disk 

Able DH/DM 

Yadic Modems 

Data products B-600-1 

Growth medium 11/780 


2.5MB total 
1035MB toted 
24 lines total 
5 300/1200 
6001pm 


$214,280 

$5,000 

$38,000 

$4,500 

$5,180 

$7,500 

$274B6F 


Large system medium system we add additional memory and 

To build a large system irom the medium system wt, 

more disk storage. Megabyte disk drive, i Mega- 

To th« all-DEC system we would add an M J u< wegc. y 
byte of additional memory, and 16 additional terminal ones: 


Medium RMB0/TU77 system 
MS750-BC 1 MB memory 
RPQ7-AA 504 MB disk 
DZ11-B 18 lines 

All-DEC Large 11/780 cost 


3.5MB total 
752MB total 
40 totsd 


$301,100 

$19,800 

$38,000 

$4,300 

$363^200 


We would put the KP07 disk on th^san^MXSSB^«3£|ter^s the itm tape 
drive, leaving the two RMB0 disks on the other MAobBUb adapter. 

To build a similar system from our ^^^^^^d^ILoreS^ 
add an RP07 to the system, or Uo^e drives; if 

dancy by putting m another Emulex dis* -c ^ ® tern could run all disks on 

either UNIBUS or disk controller ware to fail, this system coma run 

one controller on one UNIBUS. additional 

,, . , imraiiQ based large system we add an upgrade In , 

To build a UHlaJS oa^i.c loigc =j _•—..mnrv n second Emulex disk con- 

UN1BUS adapter, an additional megabyte o. memory, a se.ona n 

toiler, two 253MB AMPEX '.1300 drives, and an additional lo teman 


Medium inexpensive system 
Berkeley Upg rade Kit 
Additional UBA 
1MB Memory 

Emulex SC- 2 iY/Ampez 9300-CD 
Amp ex 930O~CD(add on} 

Abie UMAX 

Total large UNIBUS system cost 


2 total 
& f 5MB total 

602MB total 
<40 lines total 


$203,700 

$8,160 

$12,300 

$5,000 

$22,250 

$16,000 

$4,500 

$271,510" 


To make the large VAX Sfdrwtlnd ?Su1 
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Medium inexpensive system 
Berkeley Upgrade Kit 
1 MB Memory 
REP07-AA 504 MB disk 
Able DMAX 

Total large VBk/UBA system 


3.5 MB total 
800MB total 
40 lines total 


$203,700 

$8,160 

$5,000 

$48,000 

$4,500 


$269,360 


Both of these large systems include multiple disk ^roUers. m the 

tem both MASSBUS adapters are^ae^ing as &s^contr^ ^ UN]BUS/MASSBUS 

system, there are disk conlro ^ er " ° n difl ‘ 5etween the all-DEC and the not 
system there are disks or 1 both._ 1 ne. i- - {~ cking the all-DEC system, and 

S^^Slt the BK07 and also the 

Ampex storage modules in the all UNIBUS system. ^ 

It may be desirable in a system of this size to ^ onlf a 4Sips 

have a system with “ nTflnd them painful. With a 125ips drive we 

tolerable, and given our lack of experience vnth 

the 6£50bni drives do not include one here. 

the bibuopi an . . desirabls to have a second memory 

■With a system as large as thes„ it may second memory controller on 

controller and foment irith this‘soon. To run an KP07 at full 

the premises and intend. to «e^ei 1 me p Systems with two memory con- 

ssfc* sssasa zsr~ *«—a».».»—«»**•— 

for data intensive applications. of the 

thus we consider our find two sysU 

system First we add memory an ^c> - YU78 controller for two reasons: 

i. r « u e other large systems, and a o250bpi DEC 1 1T „ ■ we 0 q yet 

to provide high speed backup, and to put a RP07 on its slASSBJS, since we as yet 

have only one disk channel. 43 

We form this system as follows: 


Medium expansion system 
1 MB Memory 
TEU76-AA Tape 
Able DMAX 

Total largo expansion system 


3.5 MB total 
6250bpi 
40 Lines total 


$274,360 

$5,000 

$52,000 

$4,500 

$ 335380 " 


Recall that this system has two tape controUers^d^tiUhas an RHH 'c ^ 

and sinale drive; these coula be sold now,_ since me n^.u r 

maintenance reasons and the the tape drive is replaced by the TU78. 


• Note tha“there is no TO78 driver in 4. Ibsd. although we 

8SCCO. 


g^pest to hive one 


• AtfUGN' 
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Finally, this system to its full capacity and to make it possible to run 

the KP07’s at 2.2 MB/sec, we add an additional memory eontrodei to the sys¬ 
tem. We also flush out the system to the full 8M.B of memory. 


Large expansion system 
MS780CC mem ctlr 
K9602-HA expander cab 
4 MB Memory 


$335,880 

.5MB $28,600 

$4,460 

8 MB total $20,000 


Total full expansion system 


$386,920 
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SYSTEM SUMMARY 

h th» summarv that follows, "Ail-DEC" means that all mass storage, memory 
and terminal interface devices are DEC supplied; all systems include second ven 
dor modems and printers. 


Type CPU Mem D isk Tty 


Small 750 
Small 750 


1M 

1M 


124M 

172M 


Tape Moderns Lp r ""Price Ratio "All DEC? 1 ; 
l5iNone No $115,000 LOO Yes 
125ips None No $107,750 0.94 No 


Med 

Med 


750 
750 
Smiir'780 
Small 7BO 
Small 7B0 


2M 

_2M 

1.5M 

1.5M 

1.5M 


249M 

306M 

124M 

172M 

532M 


24 

24_ 

8 

S 


45ips 

125i ps 

125ips 

125ips 

125ios 


5 Yes $171,600 
5 Yes $141,800 


1.00 Yes 
0.83 No 


None 

None 

None 


No $244,500 
No $173,850 
No $214,260 


1.00 Yes 
0.71 No 
0.88 No 


Med 7B0 
Med 780 
780 

Large 780 
Large 780 
Large 780 
Large 760 


2.5M 

2.5M 

2.5M 


248M 

306M 

1032M 

f52M 


24 

24 

24 


125ips 

125ips 

125ips 


o. 

3.5M 802M 
3.5M 1032M 
8M 1032M 


40 125ips 
40 125ips 
40 2*125ips 
40 2«125ips 


5 Yes $301,100 
5 Yes $203,700 
5 Yes $274.360 
5 Yes $363,200 
5 Yes $271,910 
5 Yes $335,860 
5 Yes $386,920 


1.00 Yes 
0.68 No 
0,90 No 
1.00 
0.77 No 
0.92 No 
1.06 No 


CONCLUSIONS 

We have presented sample VAX systems over a wide performance rans^ using 
both att-DEC and the best available second vend” 

independently minimal cost and maximal expandability. U.e thi„ information 
wisely, price shouldn't always be the bottom line. 

Consider the 11-DEC system If you can f ord It. IT;not the scc^d-randor eq--P- 
s n {Up nackapes here is all thought to work wed on VAX hai clears. - -u can 
Xb£ cperVte sloh a system if you can get maintenance for ^ch equipment 
in-house, or through a organization associated with the vendor, o: can stocK 
gome spares for non°redundant equipment. 



AXJUGJL, 





- 20 * 


• rwk/vnj May, 19SI 


Vendor references 

VENDOR REFERENCES 


M an v fa r t ursr 

Able 

Amp ex 

Aviv 

CDC 

Data Products 

Dysan 

Emulex 

Fujitsu 

Kennedy 

National 

Printroriix 

Systems Ind. 

Trendata 

Vadie 

Varian 

Vent el 

Versatec 


Pro duct Phone 

Async. Mux (73.4) 979-7030 

Disks (*405) 255-4800 

Tape controllers (817) 933-1165 
Disks (415)-820-2933 

Printers *415) 94B-B961 

Disk Packs 
Controllers 
Disks 

Tape Transports 
Memory 
Printers 
Storage Systems 
Memory 
Modems 
Plotters 
Modems 
Plotters 


Ven dor conta ct ___ 

Able Computer (Norm Kiefer) 
Ampex (Jess Clark) 

John Connolly 

Eakins Associates (Joe Voelker) 

MQI Associates (Avery Blake) 

Dysan (Sandy Foss) 

Eakins Associates (Joe Voelker) 
Eakins Associates (Joe Voelker) 
Electronic Marketing Specialists 
Don Johnson 

Group 111 Electronics (Paul McCann) 
John Leavitt 
Trendata (Mike Jacobs) 

Moxon Electronics (Lee Berlind) 


(40B) 730-2145 
(415) 820-2933 
(415) 8202933 
(409) 245-9291 
(800) 5308514 
(403) 2404392 

(408) 732-1650 
(714) 540-3805 

(409) 787-6491 

(403) 7302900 (Ted Downs) 

(408) 279-8711 Backus Data Systems (Jeff Mas!) 
(408) 9B5-5810 (Jim Muszalski) 
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Software Support 
of 

Ubiquitous UNIX 
on a 

Multitude of Machines 


Dave Horsfall 
Computing Services Unit 
University of NSW 

(dave:unswcsu) 


The above alliterative title refers to the author's task of supporting UNIX 
on a variety of machines around campus* This version of UNIX is basically V6, 
with local AIJSAM extensions, pieces of PWB & V7, and other local modifications. 
The machines Include six PDP-ll/AO's, two LSI-ll/23's, three PDP-ll/34's and a 
PDP-11/60; and are referred to as CIVIL, C0MM40, COMM34, MECH, MATES, CSU4Q, 
CSU60, LIBRARY, FOOD (School of Food Technology), PGES (Post Graduate Extension 
Studies), MANLY (Manly Vale Water Research Laboratory) and PHAEM (Physiology & 
Pharmacology). In addition, a PDP-11/44 and a PDP-11/34 at Prince Henry Hospi¬ 
tal will shortly come under the umbrella. The intention was for each of these 
sites to appear to be the same to the user, despite the fact that no two of them 
have the same configuration; and this implies having ail systems generated from 
the one source data base. This data base is on CSU40, and various techniques 
are used to keep all the systems compatible. These techniques will be described 
for the benefit of other users who may find themselves in this situation. 

It will be seen that particular- circumstances dictated the particular 
methods used. Great emphasis is placed on MAKE, since modifying one source pro¬ 
gram will automatically invalidate all binaries of that program. Separate 
directories are used for each site, and the source is linked into each direc¬ 
tory. All programs are compiled with their own include directory, thereby 
establishing such things as site names, local hardware idiosyncracies etc. 
These directories are merelj^ sub-directories of /nsr/include, with their con¬ 
tents for the most part linked back to the parent directory. Only files such as 
local-system are private. A run file in each site’s source directory executes a 
common makefile with a parameter passed to the C compiler specifying this 
include directory. 

Unfortunately, the current version of MAKE does not allow dependencies of 
object files on SCCS files to be specified in a simple manner, since suffix 
transformation rules are used and SCCS usage involves adding an 's.' prefix. 
Various methods are used to get around this. The V7 version of MAKE does allow 
this, but is yet to be implemented on V6 - if ever. 

We turn now to a. discussion of the techniques used, followed by the method 
by which the systems are kept up to date. Samples of the makefiles are not 
included here, but their contents are rather obvious. 

The first example is the resident kernel source arrangement. Here, all 
sites have their own directory tree, and the dependencies of the objects are 
specified explicitly to the common SCCS files. /Although the compiled objects 
are kept, the source files are not; they are merely the result of an Intermedi¬ 
ate step - that of "getting" the file. Provision is made however for compiling 
and linking the system to test new modules without going through SCCS. In this 
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case the source is retained for further modification. Makefiles in each direc¬ 
tory set up the conditional compilation flags for local hardware differences, 
such as FPU,' PAGEDKERNEL, STACKLIMIT etc. It is arguable whether these symbols 
would be batter off kept in an include file, but it was done this way for his¬ 
torical reasons. In addition, most drivers include a file specifying the local 
site configuration, and various data areas are defined here. For example, the 
line printer driver will include a file, conf.lp which would be unique to each 
site. This ensures that changes to the local configuration do not affect the 
driver proper - they have nothing to do with it. The makefile dependanci.es will 
ensure that the code gets recompiled. Another example is the KL driver ~ if 
dial-up lines are installed, or if it is driving a DL.V-11E/F (on the LSI-11/23) 
then symbols must be defined to include the code to handle data-set interrupts 
and baud-rate changes respectively. 

The second technique is the primary non-resident source - the shell, editor 
etc. Since there is very little difference between the various sites for this 
type of source, there are no separate directory trees. Instead, programs are 
merely "gotten" from the SCCS file in the main directory, and the makefile run, 
specifying the i nclu de directory on the command line by hand. Few programs need 
to have a specific include directory specified; they are GETTY , WALL and WRI TE 
to get the local system name; and LPR and LPD to get the local printer confi¬ 
guration. Neither the objects nor the sources are kept since this type of 
source is basically static in nature, and usually consists of the one source 
module. Compare this situation with that of the resident kernel. 

A third technique is used on sources such as the SUN network. Much the. 
sane method is used here as for the resident kernel, except there are no SCCS 
files, since the source is basically maintained by foreign users. Each sub¬ 
directory has the source, linked into it as before, and a run file (called Make) 
merely executes the common Make file with an argument specifying the incl ude 
directory along with the rest of the argument list* One can then type "Make" 
instead of "make". Compiled objects are kept for the CSU40 system, but not for 
the others, since they only get built when the source has stabilized at CSU40. 

Maintaining the source code is one thing, but ensuring that the sites are 
kept up to date is quite another. Currently, use is made of the OSCAR program 
(r 've long since forgotten what the acronym stands for) to provide a list of all 
programs changed on a particular file system since the modification date on a 
"marker" file® The file systems specified are the root and the source. Most 
changes are picked up on the root file system, whereas the online manual is kept 
on the source file system. All sites have their own marker file, which is 
"touched" when a distribution is made to that site. Unfortunately this does not 
show which files have been deleted, only those that have been altered. This can 
be circumvented by keeping a list of all files' on a distribution and executing 
COMM (1) to generate a list of deleted files, bur it isn't worth the trouble of 
maintaining this list. Instead, every so often a fresh distribution is provided 
of the root system and the manual to all the sites, which effectively eliminates 
any rubbish that may have accumulated. It also has the beneficial side-effect 
of removing any "tampered" programs that may (and do) appear. I consider that 
this outweighs the disadvantage of the sites having to recover any programs that 
they may have installed. Of course, things like / etc/passwd , / etc/ttys and 
/etc/rc are saved first. 

I hope the above may be of some use to UNIX gurus. These techniques were 
developed over a period of about: three years, and have undergone considerable 
change. Further information such as directory listings, makefiles etc. may be 
obtained on request, or alternatively they can be inspected by anyone. I would 
be pleased to receive any comments, criticism etc of these techniques, since 
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they are not as elegant as they could be. For example, the only way to generate 
a distribution from scratch is, the brute-force technique of taking a copy of the 
CSU40 root file system and deleting by hand all the things not needed. Any 
mechanized technique would seem to imply some sort of list of files to copy, and 
this list would then become tedious to maintain on a per-site basis. 
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AUSTRALIAN UNIX USERS GROUP M EETING AT AGSM 
March j_6 f 198T 


FINANCIAL STATEMENT 


INCOME 

47 Registrations 470.00 

Cheque from Melbourne International Meeting 300.00 

Interest from Account S47069 (CSB at UNSW) 2.56 


TOTAL $772.56 


EXPENSES 


2 Refunds (Non-attendance) 20.00 

AGSM Charges (Meals + Theatre) 337.50 

Bank charges (3 Cheques) 0.90 

Cheque to Brisbane Meeting 414.16 

TOTAL $772.56 





Lindsay Harris 
7TG~SFT~ 
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From TELEMAIL Mon Apr 20 22:33:55 1981 remote from usa netmail from basser40 
From ianj Mon Apr 20 22:32:48 1981 remote from mhtsa 

pete, 

welcome to the wonderful world of international mail !! 

a bit premature BUT}i it is working 

see important messages for you at Waterloo 

ian 


From dave Wed Apr 22 10:01:21 1981 netmail from unswcsu 
Subject: Organ folders 

Hey mate - how about some sort of offer for folders for the various 
isssues of AUUGN that must be cluttering up everyones bookcase by now ? 


From bob Thu Apr 23 22:48:45 1981 netmail from basser40 

The following news item came from the U.S.A. Unix News net 
via Ianj and more networks than you can poke a stick at! 

Bob Kummerfeld 

###//##modem * news 

This month marks the twentieth anniversary of the first appearance 
of the word "modem" in computing literature.• 

The word was inadvertently contributed to the language by 
W. W. Zysick, a Bell Labs engineer, in a paper that appeared in 
the April 1961 BSTJ. There, Zysick described "a modern device 
that facilitates the connection of automatic computing machinery 
to voice-grade telephone lines' 1 . When set in type, the slugs for 
"r" and "n" in "modern" ran together, producing "modem". 

Unfortunately, shortly after submitting his manuscript to the BSTJ, 
Zysick was killed by a runaway fork-lift truck while touring WEGo's 
Submarine Cable Shop in Baltimore. Thus, he never got to see the 
proofs, and the error went undetected to press. 

Subsequently, a number.of workers citing Zysick's paper independently 
"recognized" modem as an acronym for "modulator-demodulator", 
and dropped "device" as superfluous, thereby establishing the word 
in the language. 


From dave Thu Apr 23 15:14:52 1981 netmail from unswcsu. 

Subject: computing practices 

How about a page or so in AUUGN dedicated to tricks & hints that users 
may wish to pass on to their fellow hackers ? You could call it say 
"Computing Practices" as la CACM (if they don't sue), or perhaps "Qwik 
Tricks", "Dirty Deeds" etc. I know that Kev is anxious to pass on some 
of the tricks he knows with the Editor e.g. "gwa" to make multiple 
copies of a file (I think), or "gmO" (I think) to reverse the order 
of lines in a file! I myself find "<address,address>o/$/" useful 
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to compile a columnar list of things - you just enter in the next 
line then hit ESC, then do it again for each column. Much less 
tedious than typing it out in full. Perhaps we could call it 
"Editor Tricks" with the disclaimer that not all editors may accept the 
c ommand. 


From mhtsa!pwbcc!andrew Wed Apr 22 11:12:57 1981 remote from USA netmail from basser40 
G"day mate: 

just testing the new mail service, 
andrew 


From piers Wed Apr 22 19:45:43 1981 netmail from basservax 
To: peteri:elecvax auugn:elecvax 
Subject: USA - AUST link up? 

From TELEMAIL Mon Apr 20 22:27:37 1981 remote from usa netmail from basser4Q 
From ianj Mon Apr 20 22:23:43 1981 remote from mhtsa 

piers, 

welcome to the wonderful world of international MAIL 

! ! 

tills very evening I got my program going to pick up 
those uucp files destined for austrailan distribution. 

this mail was spooled by the local mail command, then 
picked up by my new TMAIL program and collected into 
one file mail.apr2Q and then sent to TELEMAIL via TM. 

what more can I say 

cheers ian 


From kre Sat Apr 25 05:24:44 1981 netmail from basservax 
To: peteri 
Subject: auugn ... 

I think puting mail directly in AUUGN as it comes to you 
is a good idea. Keep it up. 

I also want to correct a couple of mis-statements I must 
have made in my talk at the UUG meeting in March. 

1) Vfork is not yet dead. Copy on write doesn'"t work on Comets 
for some reason relating to their micro-code bugs. The system 
has to work on those machines too, so vfork will stay till 
the bugs are removed. 

2 ) When copy on write is implemented, it will of course be 
necessary to turn off write permission in the data & stack for both 
parent & child, noyt just the child. It is also complicated 
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by multiple forks before anyone writes in the page-... 

It would also be desirable to duplicate the bottom few stack 
pages, as these are certain to be modified soon. 

3) the better i/o library relates to F77. 

4) A new tar is not new'of course* It just has an improvement 
(it keeps owner/modes of directories). Tapes produced by 
this tar are entirely compatible with those of the standard 
tar, except that if read by a standard tar, there will be 

a diagnostic when the directory is attepmted to be created 
for the second time (standard tar creates it twice if it 
sees a directory on the tape) - Not really a "new tar” 

I am also pleased to note that the UK people seem to 

have done the sensible thing & turfed out the Bell tty driver 

& created a useable one. 

However I don't think much of making UNIX pretend to be a DEC 
system, with all its crazy conventions. "D for eof is quite 
good enough for me (naturally it should be settable so 
individual users can pick what they like - but leave the defaults 
(other than '#") alone!) 


From mhtsaiianj Fri May 1 15:13:30 1981 remote from USA netmail from basserAO 
chanks for auugn 
rooks good 
yet again. 

you still haven"t mentioned ( as far as I can tell ) 
that 

1. unix 3.0 is to be. licensed to outside world - get letters in soon 

2. irma biren is no longer in charge of unix distributing .. 

so people should just write to computer information librarian .. 

also 

what are you travel type arrangements for texas ? 

glad to see you and wally wedel have got in touch.. 
euug looks well organised .. 

ian. 


From mhtsaiianj Tue May 5 23:11:08 1981 remote from usa netmail from basser40 

IIIII BBBB MM 
I B B MM MM 

I BBBB M M M 

I B B M M 
IIIII BBBB MM 

New Updates and Fixes to IBM/VU 

This is a notification of two patches to IBM/VU (Virtual 
Universe) and a new release designed for users not requiring the full 
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eapibilities of a virtual universe. 

Several users have reported errors resulting from recursive 
calls to the Universe Creation Utility (UCU). This utility, called 
from IEBSAGAN, is used to initialize the virtual space which will hold 
the universe to be simulated. On occasion, the universe created by 
this routine will contain technologies capable of creating their 'own' 
virtual universe processors, which in turn call on the UCU. While the 
stack structure supporting the UCU was designed with this in mind, no 
system can handle unlimited recursion. Release 134 will contain a 
patch that will request user verification before a new level is 
created. 

Another problem that has been experienced occurs during 
the use of black holes and neutron stars in tbs virtual universe. 
Although the mass storage media provided with the VU processor is 
of the highest quality, it can not handle storage at such a density. 
The highest density that is supported is 2.32E16 grams/cc. DO NOT 
EXCEED THIS LIMIT. Severe gravitaional effects have serious impact 
on the reliability of the system. V134 will also contain a program 
(IEB FORWARD) that can deal with these problems. 

Due for release in April is IBM/VSS (Virtual Solar System). 

This is designed for the casual user, who does not require the full 
use of a universe. One possible use of this package is to provide 
•uniform testing conditions for programs that take input regarding 
the phase of the moon. In addition, it is estimated that the cost of 
simulating the solar system and a Voyager flyby is 1/5 that of 
actually running such a mis si o il.' 

IBM Software Division 


From mhtsalianj Tue May 5 23:11:31 1981 remote from usa n a email from bassar40 
0 listen all you hackers, to my sad tale of woe 
I didn't check for table size when slots there were no mo' 

I spent much weary looking, for esoteric quirks 
Til finally the bug I found, and oh it really irks 

For if at first I'd done It right, it wouldn't have been bad 
I'd just have recompiled it once, and now would not bf ; sad 

So listen hackers, listen well, to my poor worthless rhyme 
Do it good the first time through, and save yourself some time. 


From mhtsalianj Mon May 4 20:20:38 1981 remote frem usa netmail from basser40 
Subject: bricks and watermelons... 

An explanation of why digital communications is the way of the future 
(according to a recent article in Fortune magazine): 

. . . more of the square-shaped digital signals can be transmitted 
over the same channel than analog signals, for the same reason 
that bricks, for example, can be fitted into a given space more 
compactly than watermelons ... 


From root Mon May 18 14:00:35 1981 netmail from eiec70 
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Dave: re cpio, the insistence on reading a list of file names from stdin is 
even worse when you realise how incredibly slow "find" is! What I find 
particularly revolting about cpio is that the end of a cpio dump is 
indicated by a zero-length file called "TRAILER!!!" - thus if someday some 
cretin creates one of these in his directory it will totally wreck the dump. 
There are a thousand better ways to indicate the end of a dump - one that 
pops immediately to mind Is to store an illegal inode number (Inodes are 
stored on the tape too (numbers that is) and it is easy to show that it is 
impossible to use inode numbers 0177771 to 0177777 because they wrap around). 
This is all then capped off by filling out the last block with whatever 
is left in the buffer (I bate such sloppiness!). 

Re initshs yes well you know how it goes. ... I agree it is a pain, but the idea 
with catching @ and backspace was that a person might put these in his/her 
password thinking all was OK, when in fact all was not. I guess it is 
redundant given that initsh forces the password to be longer than 8 chars 
anyway.... Given the way it is fired up : it assumes that it will be followed 
by a getty (it does leap in and alter initial shells for example). 

It does tend to ramble on, but then some students here are pretty thick. 

Re iomove&mem: apart from making reads/writes on mem a zillion times faster 
(ps really flies down here now compared to how slow it used to be), 
it also had. the desirable effect of make word operations do word operations 
and not behind-the-scenes byte operations. It does assume that you are using 
a mapped__buffers system i.e. ka5 is free and clobberable without restoring. 

If you are not using mapped_buffers than the changes you should make are 
obvious. You should also look at iomove - I altered it slightly to be 
more efficient on certain types of odd-byte reads/writes (there tended to be 
code in various drivers to iomove up to an even number and then do the last 
byte using cpass or passe - I moved this code to where it should have been 
in the first place!) 

kev 


From root Wed May 20 15:24:58 1981 netmail from basservax 
To: gurus 

Subject: CSIR0 node name change 

Please inform any CSTR0NET usars that the basser40 node name will change 
from "*mid” to "*suu" in about 2 weeks. 


From mhtsa!ianj Wed May 27 16:25:53 1981 remote from usa netmail from basser40 
Almost anything in software can be implemented, sold, and even used 
given enough determination. There is nothing a mere scientist can say 
that will stand against the flood of a hundred million dollars. But 
there is one quality that cannot be purchased in this way — and that 
is reliability. The price of reliability is the pursuit of the utmost 
simplicity. It is a price which the very rich find most hard to pay. 

C. A. R. Hoare 


From judy Sun May 31 21:50:14 1981 netmail from basservax 
To: ianj:usa piers chris peteri:elecvax jefft:elecvax 
Subject: more Hoare 


"Of course there are a lot of mistakes made in every branch of 
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engineering, and one of the attributes of a good engineer, 1 hope, 
is that he. avoids obvious mistakes- 

Now there are two ways of avoiding obvious mistakes, which 
are open to every engineer: one way is to make things so simple that 
there obviously aren't any mistakes; and the other way is to make 
things so complicated that there aren't any obvious mistakes" 
C.A.R.Hoare 


From mhtsaiianj Sun May 31 12:07:53 1981 remote from usa netmail from basser40 
... when we recognize the battle against chaos, mess, 
and unmastered complexity as one of computing science's 
major callings, we must admit that "Beauty is our Business." 

E. W. Dijkstra 


From mhtsatianj Thu Jun 4 09:42:17 1981 remote from usa netmail from basser40 
I conclude that there are two ways of constructing a software 
design: One way is to make it so simple that there are obviously 
no deficiencies and the other way is to make it so complicated 
that there are no obvious deficiencies. 

C. A. R. Hoars 


From mhtsaiianj Sun Jun 7 20:49:03 1981 remote from usa netmail from basser40 

I have just been examining my mail loopback statistics for last few weeks 

(ie the mail X send myself via australia) 

and am most happy to report that nearly always 

I receive my mail back the VERY next day. 

no mail has been lost since the NINE bug was fixed 

this is just great !! 

ian 


From dave Fri Jul 03 12:26:50 1981 netmail from unswcsu 
To: auugn:elec70 
Subject: memory wanted 

Could you please place a "want ad" in AUUGN ? I am looking around 
for 32K core memory to take our 11/40 up to 128K. I have no wish 
to scrap the lot & replace it with M0S - I just want extra core. 

PS 

Those quantities are in words, not bytes. 

(Dave obviously wants CHEAP, eg second hand core..... ED) 

From root Sat Jul 4 15:17:19 1981 netmail from elec7Q 
Subject: Peter Dalwood 

from UCC (Syd. Uni) on 692-3491 would like a copy of the paper delivered 
by Ross Gaylor at the last Unix Meeting (AGSM) - does AUUGN have a copy? 
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kev 

(No, sorry I dont have one. Pester Ross...... ED) 


From dave Thu Jul 9 11:22:44 1981 
Subject: dd conv=swab 

You may like to publish this. note. If the file has an odd number of 
words, the last word never gets swabbed. The fix is just to remove the 
“& "01” which some idiot had coded. The right shift automatically takes 
care of the case where there is an odd number of bytes. 

>From bob Mon Jul 13 10:45:56 1981 netmail from basser40 

Date: Mon Jul 13 10:44:59 1981 

From: Bob Kummerfeld <bob at basser40> 

To: augn at elec70 

To: augn:elec70 

Subject: A note for the next AUGN 
Cc: peteri at elecvax 

Peter, 

This is a short note for AUGN to let people know what has been 
happening in the area of networks, the Sydney Unix Network in 
particular. 

We now have 13 machines on the SUN as "full" members, 
i.e. running the network daemon and supporting file/mail 
transfer. The 11/44 at Sydney University Computing Centre has a 
working link into the net but hasn't yet got the software 
installed. There are another half-dozen machines connected to the 
network that can be "con"ed to from other systems, these are 
smaller machines or larger machines like Cybers. 

The most important development in the network area has 
been the connection of the Basser 11/40 to the CSIR0NET. This 
link operates with the "mx” protocol and allows people to get out 
into CSIR0NET and connect to other hosts, it also allows people on 
CSIRONET to connect to the Sydney Unix Net. This software to make 
this connection is now officially supported by CSIR0 ICR and is 
available to allow Unix systems anywhere in Australia to connect 
to CSIRONET. CSIRO have several Unix systems in the Division of 
Maths & Stats that will soon be connected. Unix systems in the 
University of Tasmania and Monash are to be connected to CSIRONET 
soon with other University Unix sites interested. 

Piers is going to modify the existing SUN net. daemon to 
take care of part-time connections via CSIRONET thus allowing 
mail/files to be transfered between Unix systems connected to 
CSIRONET. This will make communication between Unix users much 
easier. 

The "mx" protocol has been enhanced for the CSIRONET 
connection to provide for call establishment, call clear, line mode 
change (allows a true raw mode across csironet!!) and full CRC 
error checking. These enhancements are not necessary for 
dedicated connections normally but CSIRO felt they were needed 
for connection to their net. 

Another planned enhancement for the SUN software is the 
ability to multi-drop files/mail. This will allow a single copy 
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of a mail item that, was directed to many people on a remote machine 
to be passed around the net. Only at the final delivery 
stage will multiple copies be created and mailed to the 
destination users. 

At the last AUG meeting Ian Johnston and I mentioned a 
mail relay system that we planned to construct that would allow 
mail from the SUN to be delivered to machines in the USA on 
UnixNet, uucpnet* ARPANET or any network connected to them* This 
system is now in experimental operation and is being used to keep 
in contact with people such as Bill Joy at Berkeley as well as 
Ian Johnston and Andrew Hume at Bell. Unfortunately the system 
cannot be released for general use at the moment since Basser is 
paying the trans-pacific network charges and can't afford much! 

The charge is 60cents per thousand characters - it doesn't take 
long to mount up. 

Bob Kumraerfeld 
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TELEPHONE: 692 .H91 

692 1122 
EXT 3491 


UNIVERSITY COMPUTING CENTRE 

THE UNIVERSITY OF SYDNEY 
NSW 2006 

13 April 1981 


iN REPLY PLEASE QUOTE: 


" '% 



WHY DOES DEC THINK THAT THE NUMBER 44 LIES BETWEEN 45 & 70 . 


The 11/44 is the latest in the range of PDP11 ~ perhaps the last 
if DEC turn all their efforts to designing VAX's. According to 
the processor handbook, the 11/44 has a shade more power than 
the 11/45, and the cost of an 11/34. Architecturally, the 44 
is closer to the 70, and except for a few small differences, 
and the speed, looks identical to it. It has 22 bit. addressing 
(Unibus maps), separate I & D space, supervisor mode, and an 
8K cache. On the other hand, there is no Massbus. 

Physically, the 11/44 comes in a cabinet about the size of an 
RK07 disc drive. It is, however, the most badly designed box 
ever. The only cable exit takes a Unibus cable and that is 
all I We have half our cabinet empty waiting for backplane, 
with no chance of leading cables out of it, if it was there. 


Sydney University Computing Centre bought, a minimum configura¬ 
tion from DEC for $28,000 - processor, 256Kb of memory, and 
two TU58 DECTAPE II. cassette tape drives. Since then we have 
hooked on two RM02 drives from Digital Electronics, a TU10 
look-alike (except it’s dual density), a DZ11-E, a DU11 Syn¬ 
chronous interface, an optical mark reader, 3 printers and 
a card reader, most of which is plugged into a DD11-CK 
extension cabinet. 

The processor comes on 4 hex cards, memory comes in 256Kb chunks 
of.ECC mos memory, up to 1 Mb. There is an optional floating 
point processor, and also a rather groovy commercial instruct¬ 
ion set processor which enables a number of instructions like 
block moves, character searches and translations, edits, and 
the like (just like a VAX). 
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Other than optional stuff,, the processor executes all 11/70 
instructions, plus a few others, just to give you the chance 
to write incompatible software. There is a CSM instruction 
that calls supervisor mode and MFPT instruction which returns 
a processor specific subcode--“Currently 0. 

The TU58 is a weirdp too. It is a replacement for the old 
DECTAPE, so it is a random access tape. It uses a cassette 
a bit smaller than an audio cassette and is virtually fool¬ 
proof - DEC say that removing the cassette while writing may 
cause loss of data, otherwise it is safe. There are absolutely 
no switches or buttons to misposition or mispress. The best 
part is that it interfaces to the processor through an ordinary 
KL11 asynchronous terminal line. There is a handshaking 
protocol for accessing any of the 512 blocks on the cassette. 

In theory, you could run UNIX off them - how excruciating. 

These things are now standard on 11/44 systems—-an improvement 
of the paper tape. 

The console has a micro, allowing interactive examination and 
depositing, booting from different devices (you have to 
purchase different ROMs), single stepping and tracing, stepping 
through the microcode, self testing, examination of all the 
internal registers of the machine, loading from paper tape 
and dumping to paper tape. More civilized than flick switches I 

So much for the hardware. The standard level 7 tape will not 
boot and requires a few small changes to bring up. Fortunately, 
the level 7 system that had run occasionally on the 11/34 at 
the UCC, booted and ran without change. Thereafter, the comedy 
begins. Online RESTOR will not load-~it needs separate I & D. 
You can’t load RESTOR off the tape (it gives strange error 
messages). You, therefore, have to boot standalone RESTOR from 
the disc (it had to know about RMQ2s any way so a driver had to 
be written) and copy the tape to disc. 

Once a mountable file system is available, the following changes 
afe needed: 

a. Standalone boot has to know about RM02s. (change /usr/src/ 
cmd/standalone/conf*c) and add a driver. 

b. The il/44 cache has a different format to the 11/70. For an 
11/7.0, both mch.s and /usr/src/cmd/standalone/M,s move 3 to 
the cache register MSCR. For an 11/44 change this, to 0201. 

c. Since the 11/44 does not have a Massbus, all drivers have 
to do a call to MAR ALLOC for raw 7 I/O to set the Unibus map 
registers. Similarly, the standalone utilities (mainly 
boot) have to set them, otherwise the initial disc read 
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flakes out with leftover rubbish. 

ll/70s do not have this problem, as Massbus disc control¬ 
lers have 22 bit address registers. I can’t see how to 
boot standard level 7 from RK05s on an 11/70. 

d. /usr/sys/trap.c handles memory parity errors and prints 
out the cache registers. Some of these don't exist on 
the 11/44, so change it to print out the ones that do. 

The other alternative is to bring it up as an 11/45 in 
18-bit mode (OK if you have only 265Kb). This has the 
advantage of no messing about with Unibus maps, /usr/ 
src/cmd/Ms sets MMR3 to 65 to enable 22 bit mapping and 
Unibus maps. Change this to 5 and b & c above, disappear. 
Similar code exist in mch.s, but if the normal boot 
sequence is followed, it is never executed. 

After that, it is all fairly clear cut, converting the dis¬ 
tributed system to a usable one, installing bug fixes (is 
there a list anywhere?), creating the floating point simulator 
library (the makefile fails!) and the C compiler, installing 
all the non-Bell drivers, etc. etc. 

The system itself is stable, and only goes down when the discs 
fail (as they do regularly - Ampex discs on an Emulex control¬ 
ler - aarrgghh!) 1 gave up.waiting for the much vaunted DEC- 
supplied Unix tape, and it only took about 50 lines of codes 
anyway. 

My final comment is addressed to the unremembered (sorry) 
Queensland site who were going to run a similar system to us 
““ contact me for a disc copy or code fixes. 


GEOFF COLE 
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Adrian Freed 

Groupe Informatique, 

L.E.R.S, 

58 Rue de la Glaciere, 

75013 PARIS 

France 

589 8929 ext 227 
1/6/81 


Dear Peter, 


This is the first letter from the French UNIX connection and is intended to 
give readers of AUUGN a programmers perspective of what is happening at 
LERS, a commercial licence holder, where I now work. Ian Perry (my boss) 
has given a socio-historic account in a previous issue. 

Incidently, there seems to be a lot of movement of UNIX people at the 
moment. I met Peter Lamb from Melbourne on the plane coming here. He is 
working in Switzerland. Richard Miller is currently working at Oxford. 


1. Installation 
Hardware: 

1 PDP11/70 with remote diagnostics 

1 RP04 

1 TU10 (the tapes keep falling of the spindle!) 

2 300 Mbyte CDC drives with System Industries Massbus controller 

>30 Perkin-Elmer fox terminals 

7 DZ/ll's 

3 DL/ll's 

1 KMC/11 (currently unused) 

2 Anderson Jacobson high quality printers (Qume mechanism) 

1 Benson pen plotter 

3 Printronix printer/plotters 

1 Matrox 512x512 video display device 

1 Imlac Calligraphic terminal (not connected to 11/70) 

1 Wang word processing system 

Communications hardware including time division and statistical 
multiplexers, leased lines, dial-up lines, 300,1200,9600 and 72000 baud modems. 

DEC have installed a remote diagnostic facility, which allows them to stick 
fingers in the CPU from a distance. I miss the dull red glow of the idle 
loop on the front panel, but thats the price of progress I guess. Also 
supported, on terminal connections, are about 12 LSl/li based systems for 
real-time work. 1 say about 12, because some are still being configured 
from bits ordered from different DEC compatible suppliers. The "various 
configurations are subsets of the following: 
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1 LSI li/23 

1 LSI 11/1 

2 double density, double sided floppy disks 

1 real-time clock 

1 line-time clock 

1 16 channel A/D, 2 channel D/A system 

1 parallel I/O board 

Dee, Intel and Dataram memory 
Serial asynchronous interfaces 

Work is also being done with a 20Mb Winchester disk system. 

Software: 

LERS runs a reasonably standard v7, with named pipes. The disk driver was 
developed locally. There is some use of 'ex', which is quite pleasant as 
most of the terminals run at 9600 baud. 

People: 

The computer group consists of an Australian, a Cameroonian, a Dutchman, 
three Frenchman, an Englishman and a Scotsman. 


2. Activities 

2.1 Data bases 

A stable, reliable and simple data base system, designed and implemented by 
Jeff Rottman forms the basis of 12 data bases. 

2.2 Signal Processing * 

The LSI/ll systems are used to acquire, store and process data of various 
forms. Certain processing is done on the 70. The LSI systems have a remote 
directory on the 11/70 known to the micro as /70. File transfers are 
managed using the line-protocol. The data is from ECG, EEG, liquid 
scintillation counters, Behavioural control boxs and any other laboratory 
equipement, that happens to oe around. 

2.3 Word Processing 

In French and English, using 'nroff', unsophisticated macros. An interface 
between the Wang system and UNIX is being developed. The backspace key is 
not used to erase characters. It is used to overstrike accents. The 'del'’ 
key is the erase character. ~C and ~P are the DEL and QUIT characters 
respectively. This can be a bit confusing to a new-comer. 

2.4 Pert networks 

Software is being developed for project planning to augment the simple PERT 
networks, which are currently used. 

2.5 Miscellaneous 

There is a statistical package (ISP) which is part of the statistical 
support provided by the group. There are programs for chemical naming, 
costing and inventory. There is an extensive graphics library and an 
interactive graphics language based on it (LIG). 
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3» /* social */ 

Of course, one of the great things about working at LERS is Paris. My first 
impression was that Paris is cold. This impression has gradually matured to 
the stage where 1 can say Paris ranges from bloody freezing to cold. 
However, if you can master the lookahead required on storage heaters it can 
be quite pleasant. A tee-shirt is about as useful as a pair of sunglasses 
or a can of Aerogard. Paris is famous for a lot of other things. It 
positively brims with priceless art collections, museums and architectural 
marvels and monstrosities. It seems that any excuse for an exhibition or 
trade fair suffices. There are at least 200 cinemas and you can see films 
from any country sub-titled or dubbed in French. Most films-are also shown 
in their original form somewhere in Paris. 

Food is of course very important to the French. The range of cheeses 
available is simply mind-boggling. My first impression was that 30% of them 
were like Camemhert. Actually, the ones that aren't breathing and leaping 
at you are Camembert, an innocent friendly cheese. Its the ones that pulsate 
and grow, before your eyes, that you have to be careful with. This reminds 
me of a joke, which I will try to translate: 

Indignant customer in a restaurant. 

M: Waiter, is this coffee or tea? 

W: What does it taste of. Sir? 

M: Petrol! 

W: Then, that would be the tea. Sir. 

M: And Waiter what about this cheese, it practically walks? 

W: Ah, that cheese comes from Normandie, its a long way. * 

Believe me, its funnier in French. 

A decent sized steak is something that French people only dream about. You 
have to mortgage your house to buy one. The meat pie does not exist in 
France (sorry Kev). In fact, it is impossible to buy a pie. 

The basic rule of French food is that they eat every part of anything that 
moves. This includes snails, frogs, goats, squirrels, rabbits, hare etc. I 
can live without snails, but frog's thighs (as the French call them) are 
rather good. 

Actually, the hardest thing to get used to is wearing a suit to work 
(IRP: He doesn't very often). 

If anyone in the UNIX community happens tc be in Paris do get in touch. 


Yours Faithfully, 



Adrian Freed 
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UNIVERSITY OF NEW SOUTH WALES 


P.O. BOX 1 * KENSINGTON • NEW 50UTH WALES • AUSTRALIA * 2033 
TELEX AA26054 * TELEGRAPH: UNITECH, SYDNEY * TELEPHONE 663 035! 



SCHOOL OF ELECTRICAL ENGINEERING 


EXTN. 

PLEASE QUOTE 

8th July 1981 


Peter Ivanov, 

AUUGN Newsletter Editor, . 

Dept, of Computer Science, 

University of N.S.W. 

Dear Peter, 

I am interested in making contact with any Australian Icon users or 
intending users, and I think that AUUGN is probably the most effective 
method. Icon has been suggested as an alternative to Snobol in our second 
year Programming I course so 1 am interested In finding out about other 
peoples'" experiences with Icon, both for teaching and research. I can 
be contacted on the Sydney Unix network as davec:elecvax. 


Yours sincerej.y, 

*2) k tv'V.v.f' 1 - 

David Carrington. 


Lecturer, 

Dept, of Computer Science . 
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Position being adve r tised at U.N.S.W., 
for Analyst / Program mer 


After the normal 3 month probationary period 3 the successful, applicant will be 
graded according to the following scales 

Par Exceed s Job Requirements 

Lifts buildings and walks under them. 

Catches speeding bullets with his teeth and eats them. 

Kicks locomotives off the track. 

Freeses water with a single glance. 

Gives policy to God. 

Exceeds Job Re quireme nts 

Leaps tall buildings with a single bound. 

Is faster than a speeding bullet. 

Is more powerful than a locomotive. 

Walks on water. 

Talks with God. 

Meets Job Requirement s 

Must take running start to leap over tall buildings. 

Is just as fast as a speeding bullet. 

Is stronger than a bull elephant. 

Walks on wafer of indoor swimming pools. 

Talks with the angels. 

Needs Som e Improvement 

Can leap over short buildings only. 

Wounds self with bullet when attempting to shoot. 

Recognises locomotives two out of three times. 

Swims well. 

Talks with self. 

Nee ds Muc h Impro'' enent 

Crashes into buildings when leaping. 

Is not issued with ammunition. 

Smells like the. bull elephant. 

Drinks water in emergencies. 

Argues with self. 

Dogs Not Meet Minimum Requirements 

Cannot recognise buildings at ail.. 

Wets himself with water pistol. 

Says 15 Look at the ehoo choo * 

Plays in mud puddles* 

Loses arguments with self, 
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